Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81433A67B6 for ; Mon, 30 Aug 2010 15:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIldD0RpkW9W for ; Mon, 30 Aug 2010 15:25:27 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id BCAA53A68D3 for ; Mon, 30 Aug 2010 15:25:27 -0700 (PDT) Received: by gxk20 with SMTP id 20so2645446gxk.31 for ; Mon, 30 Aug 2010 15:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XjTM6p+WXwr7atiV0lngkymhVvHnjxy9SLxJUefhNHk=; b=MPtuOLPNG23XDHOfIC0NVh2CLYV37PLLCbmpMZBAzzA5Ir4uYkKho40oidIcZY100A oedhRImi54lIlmQ6c9zfwWheFvWVQbg57cI6jb7M5DOZbNgVh4/kLKH7RUcHkPfyl0TV G7RaYFCNZ3ppJDLdzP58XWN5LalYUiVahkpxM= 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:content-transfer-encoding; b=T8YE2/CMjtUsmA2gVMYxiPUWHWI2/1xW8F+QV0bb1ZY6j4p98dTB6mEWCVqc8K6idh 8KrAxfFvGheE91XL+OPEDgtwzIfYaaCxRrAq69kumfmxCUS4x61aAGuOr1yjGs4VfJ1o nKHuVGbRYosA9yszSlTwfmXV/fp60RaNKvjUY= MIME-Version: 1.0 Received: by 10.90.98.4 with SMTP id v4mr4090347agb.58.1283207151267; Mon, 30 Aug 2010 15:25:51 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Mon, 30 Aug 2010 15:25:51 -0700 (PDT) In-Reply-To: <1EBC6F2B-B0BA-4C11-B9EA-7041BB9C057C@icsi.berkeley.edu> References: <4C7B7275.30903@nic.cz> <1EBC6F2B-B0BA-4C11-B9EA-7041BB9C057C@icsi.berkeley.edu> Date: Mon, 30 Aug 2010 18:25:51 -0400 Message-ID: From: Phillip Hallam-Baker To: Nicholas Weaver Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] SSHFP (is there a work to do) vs. Securing Last Mile X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 22:25:29 -0000 DNSSEC is an internet security scheme not an intranet security scheme. There is a big difference in the approaches and the constraints that are relevant. The objective of DNSSEC is to secure the DNS protocol. As an enterprise I could not give a hoot for the security of the DNS protocol unless it negatively impacts my actual security objectives. In particular DNSSEC is designed to ensure that a client has a faithful copy of the authoritative DNS, I don't want my machines to connect to the authoritative DNS and to connect to every Internet site any more than I would want them to run every program run by every random bozo I never met. In short, enterprise security is not the same as what individuals chose to run for themselves. What is taken to be a demand for 'security' is more often a regulatory requirement for compliance. And it is instructive to see how very subtle changes in a system can create massive compliance issues. So for example, I move from using SSH with bilateral keys to SSH with keys stored and distributed via the DNS. It is really easy to show that this offers the same theoretical degree of control if the applications are using a trust root that I control or I have a direct contractual agreement with. What do I tell the auditor if I am trusting a root I don't control and nor does the party being authenticated? It shows up fairly starkly in SSH because we are moving from an environment with direct key management with an organized hierarchy. It is much harder to spot this situation where we are talking about moving from 99% of traffic having no security to having better than nothing security. On Mon, Aug 30, 2010 at 2:58 PM, Nicholas Weaver wrote: > > On Aug 30, 2010, at 1:57 AM, Ond=C5=99ej Sur=C3=BD wrote: >> Bigger: >> 3) Secure Last Mile: I think it was already stated here (or on other pla= ce) that simply trusting AD bit is not sufficient, and there is a strong ne= ed for securing last mile. =C2=A0Could it be a validating resolver on local= host (but it's not secure on multi-user machine). =C2=A0Could it be IPSec (= but this is probably valid only in strictly controlled environment). =C2=A0= Could be SIG(0) to your resolver? > > Actually, the resolver on localhost is secure on a multi-user machine, in= the sense that any adversary who could corrupt that resolver could corrupt= other parts of the victim. > > IPSec or others to a "trusted" secondary resolver is, IMO, silly: =C2=A0D= NSSEC is all about not needing to trust the infrastructure, so why change t= he DNS client model to one that establishes a 'secure' connection to a 'tru= sted' resolver instead of just having the client validate the information d= irectly and, if it can't validate the information, fetches it for itself if= you don't trust the external resolver? > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5ACF3A68B9 for ; Mon, 30 Aug 2010 15:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5YrhOY8VHNK for ; Mon, 30 Aug 2010 15:23:19 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id DFE363A67B6 for ; Mon, 30 Aug 2010 15:23:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=dby3RqH1bQzCUpDkO+LyuZl7ttzUqy+cXxW1XKcbeym+00KVZKmyiKTSaJbzXuwS; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.29] (helo=mswamui-cedar.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OqClZ-0003eW-Dh; Mon, 30 Aug 2010 18:23:49 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 30 Aug 2010 18:23:49 -0400 Message-ID: <22505293.1283207029436.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Date: Mon, 30 Aug 2010 17:23:49 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Paul Hoffman , keyassure@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606884aa35e10ef8ef0c7f48e4d0e6e7eaf2d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.29 Subject: Re: [keyassure] Trust models (was: Securing Last Mile) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 22:23:20 -0000 Paul H., and all, Yes, nicely stated. -----Original Message----- >From: Paul Hoffman >Sent: Aug 30, 2010 5:14 PM >To: keyassure@ietf.org >Subject: [keyassure] Trust models (was: Securing Last Mile) > >At 11:58 AM -0700 8/30/10, Nicholas Weaver wrote: >>On Aug 30, 2010, at 1:57 AM, Ond=C3=9Eej Sur=C2=98 wrote: >>> Bigger: >>> 3) Secure Last Mile: I think it was already stated here (or on other pl= ace) that simply trusting AD bit is not sufficient, and there is a strong n= eed for securing last mile. Could it be a validating resolver on localhost= (but it's not secure on multi-user machine). Could it be IPSec (but this = is probably valid only in strictly controlled environment). Could be SIG(0= ) to your resolver? >> >>Actually, the resolver on localhost is secure on a multi-user machine, in= the sense that any adversary who could corrupt that resolver could corrupt= other parts of the victim. >> >>IPSec or others to a "trusted" secondary resolver is, IMO, silly: DNSSEC= is all about not needing to trust the infrastructure, so why change the DN= S client model to one that establishes a 'secure' connection to a 'trusted'= resolver instead of just having the client validate the information direct= ly and, if it can't validate the information, fetches it for itself if you = don't trust the external resolver? > >This exposes something that people in the security community constantly gr= apple with / trip over: who is the trust anchor? In the "localhost" scenari= o above, it is the DNSSEC root or whichever lower DNSSEC trust anchors you = have manually installed. In the "IPsec or others" scenario, it is a trusted= third party who is doing resolution for you, such as "your ISP" or "your c= orporation". > >Those are radically different models that are desired by different types o= f people with different needs. You can't say one is more important than the= other because you are making a value judgement for people with whom you di= sagree. > >The "localhost" solution is defined today. The "IPsec or others" is too, b= ut in a zillion different ways. If there is interest in making the latter m= ore focused, that's great, but such work is for the DNSEXT WG, not here. > >--Paul Hoffman, Director >--VPN Consortium >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, = strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liabilit= y depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.co= m Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C933A6887 for ; Mon, 30 Aug 2010 15:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.761 X-Spam-Level: X-Spam-Status: No, score=-99.761 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Zcnb2jzgFY6 for ; Mon, 30 Aug 2010 15:13:38 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 8AACC3A67E3 for ; Mon, 30 Aug 2010 15:13:38 -0700 (PDT) Received: from [10.20.30.158] (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 o7UME7eC010637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Aug 2010 15:14:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1EBC6F2B-B0BA-4C11-B9EA-7041BB9C057C@icsi.berkeley.edu> References: <4C7B7275.30903@nic.cz> <1EBC6F2B-B0BA-4C11-B9EA-7041BB9C057C@icsi.berkeley.edu> Date: Mon, 30 Aug 2010 15:14:02 -0700 To: keyassure@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: [keyassure] Trust models (was: Securing Last Mile) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 22:13:40 -0000 At 11:58 AM -0700 8/30/10, Nicholas Weaver wrote: >On Aug 30, 2010, at 1:57 AM, OndÞej Sur˜ wrote: >> Bigger: >> 3) Secure Last Mile: I think it was already stated here (or on other place) that simply trusting AD bit is not sufficient, and there is a strong need for securing last mile. Could it be a validating resolver on localhost (but it's not secure on multi-user machine). Could it be IPSec (but this is probably valid only in strictly controlled environment). Could be SIG(0) to your resolver? > >Actually, the resolver on localhost is secure on a multi-user machine, in the sense that any adversary who could corrupt that resolver could corrupt other parts of the victim. > >IPSec or others to a "trusted" secondary resolver is, IMO, silly: DNSSEC is all about not needing to trust the infrastructure, so why change the DNS client model to one that establishes a 'secure' connection to a 'trusted' resolver instead of just having the client validate the information directly and, if it can't validate the information, fetches it for itself if you don't trust the external resolver? This exposes something that people in the security community constantly grapple with / trip over: who is the trust anchor? In the "localhost" scenario above, it is the DNSSEC root or whichever lower DNSSEC trust anchors you have manually installed. In the "IPsec or others" scenario, it is a trusted third party who is doing resolution for you, such as "your ISP" or "your corporation". Those are radically different models that are desired by different types of people with different needs. You can't say one is more important than the other because you are making a value judgement for people with whom you disagree. The "localhost" solution is defined today. The "IPsec or others" is too, but in a zillion different ways. If there is interest in making the latter more focused, that's great, but such work is for the DNSEXT WG, not here. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E23B3A68D0 for ; Mon, 30 Aug 2010 14:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.839 X-Spam-Level: X-Spam-Status: No, score=-4.839 tagged_above=-999 required=5 tests=[AWL=-1.440, BAYES_50=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGC7eGkoNm4c for ; Mon, 30 Aug 2010 14:55:16 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 4FFD83A6895 for ; Mon, 30 Aug 2010 14:55:16 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o7ULtfDY015737; Mon, 30 Aug 2010 21:55:41 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o7ULtf8j015736; Mon, 30 Aug 2010 21:55:41 GMT Date: Mon, 30 Aug 2010 21:55:41 +0000 From: bmanning@vacation.karoshi.com To: keyassure@ietf.org Message-ID: <20100830215541.GA15702@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [keyassure] rapid conclusion or pandoras box X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 21:55:17 -0000 a quick review of the recent thread on SSHFP led me to go look at the repository, here: http://www.iana.org/assignments/dns-parameters and there seem to be a number of potentially applicable RR types. I've extracted the following list: SIG 24 for security signature [RFC4034][RFC3755][RFC2535] KEY 25 for security key [RFC4034][RFC3755][RFC2535] GPOS 27 Geographical Position [RFC1712] LOC 29 Location Information [RFC1876] EID 31 Endpoint Identifier [Patton] NIMLOC 32 Nimrod Locator [Patton] KX 36 Key Exchanger [RFC2230] CERT 37 CERT [RFC4398] DS 43 Delegation Signer [RFC4034][RFC3658] SSHFP 44 SSH Key Fingerprint [RFC4255] IPSECKEY 45 IPSECKEY [RFC4025] DNSKEY 48 DNSKEY [RFC4034][RFC3755] NSEC3PARAM 51 NSEC3PARAM [RFC5155] HIP 55 Host Identity Protocol [RFC5205] RKEY 57 RKEY [Reid] TALINK 58 Trust Anchor LINK [Wijngaards] at one point or another, all of these either have delt with certs/naked keys. so how specific is this work going to be? just SSHFP <-> openssh or as DRC seems to suggest, are more careful review of an API method? --bill Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8A53A6814 for ; Mon, 30 Aug 2010 12:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCktrek5EdaD for ; Mon, 30 Aug 2010 12:35:23 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 8D4DD3A69F2 for ; Mon, 30 Aug 2010 12:35:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id C5B85DF62F4; Mon, 30 Aug 2010 12:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiObAHUDFRL8; Mon, 30 Aug 2010 12:35:51 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 10111DF62E3; Mon, 30 Aug 2010 12:35:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <9B952A81-2366-49F6-A6CE-029041841525@kumari.net> Date: Mon, 30 Aug 2010 12:35:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A9DFE76-0E00-497A-BD10-10EDFAB97841@virtualized.org> References: <4C7B7275.30903@nic.cz> <707CC634-EDB5-4E11-930F-97342DBEFACD@virtualized.org> <9B952A81-2366-49F6-A6CE-029041841525@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] SSHFP (is there a work to do) vs. Securing Last Mile X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 19:35:24 -0000 On Aug 30, 2010, at 11:52 AM, Warren Kumari wrote: >> There's TSIG too. > No, no there isn't. Here is where I go into my standard rant about the = fact that standard stub resolvers don't support either of these Implementation detail (half :-)). I'm sure the fine folks at ISC and/or = NLNetLabs would be more than happy to implement the appropriate hacks to = resolv.conf and stub resolvers if you wave money at them. I suspect the = reason TSIG/SIG(0) protected channel between validating resolvers and = stub resolvers hasn't been implemented to date is (a) no point given = DNSSEC hadn't been deployed, (b) IPSec does the same thing and already = exists and/or (c) running a local validating resolver is easier. Regards, -drc Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC1D83A6837 for ; Mon, 30 Aug 2010 11:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2tleeODayv1 for ; Mon, 30 Aug 2010 11:58:15 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id ED7773A6814 for ; Mon, 30 Aug 2010 11:58:14 -0700 (PDT) Received: by gwb20 with SMTP id 20so2569557gwb.31 for ; Mon, 30 Aug 2010 11:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=n0YrHO9K/BNgzIjTG6YmOaXlHB67jeCPsyeoknZPKOo=; b=T71RlzFbEn/ffQHBbW9dzjbfBTpP0+PreL+AN+swa/7UFsQIpTdpTaIHuYp7NsLZ0p JGSvRISRNPcP69CAzoy+WlKx5CHulWDaPcYqnbset0RSb18sb9mnBPOfOntm9eL0bEWG Med8L6OoTnCCw8AOpm3NVCpyh5WSgbAl61hqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=l4m10IZ+Pzz47tMCEvTOXySvZeoXfcp6agWxD+CVhIPmbpSodJUWmukYqwzc9qlUHH WIYNrhQf02iOAhVNblVV9+glSfDQnTaQdxlnw1lhPPg31pyIfPaOR1q+sib/gUNo3PFb owFdW4Vwdr2pZKfgQGvJYRYz3CQpNezWBvepA= Received: by 10.151.130.20 with SMTP id h20mr423091ybn.308.1283194725550; Mon, 30 Aug 2010 11:58:45 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id r3sm7796237ibk.7.2010.08.30.11.58.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Aug 2010 11:58:44 -0700 (PDT) Sender: Nicholas Weaver References: <4C7B7275.30903@nic.cz> In-Reply-To: <4C7B7275.30903@nic.cz> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 Message-Id: <1EBC6F2B-B0BA-4C11-B9EA-7041BB9C057C@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Mon, 30 Aug 2010 11:58:41 -0700 To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] SSHFP (is there a work to do) vs. Securing Last Mile X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 18:58:16 -0000 On Aug 30, 2010, at 1:57 AM, Ond=C5=99ej Sur=C3=BD wrote: > Bigger: > 3) Secure Last Mile: I think it was already stated here (or on other = place) that simply trusting AD bit is not sufficient, and there is a = strong need for securing last mile. Could it be a validating resolver = on localhost (but it's not secure on multi-user machine). Could it be = IPSec (but this is probably valid only in strictly controlled = environment). Could be SIG(0) to your resolver? Actually, the resolver on localhost is secure on a multi-user machine, = in the sense that any adversary who could corrupt that resolver could = corrupt other parts of the victim. IPSec or others to a "trusted" secondary resolver is, IMO, silly: = DNSSEC is all about not needing to trust the infrastructure, so why = change the DNS client model to one that establishes a 'secure' = connection to a 'trusted' resolver instead of just having the client = validate the information directly and, if it can't validate the = information, fetches it for itself if you don't trust the external = resolver? Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D273A6814 for ; Mon, 30 Aug 2010 11:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC2FJ+SBluZ8 for ; Mon, 30 Aug 2010 11:52:18 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id E98973A67E5 for ; Mon, 30 Aug 2010 11:52:17 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id B97AFDEE003; Mon, 30 Aug 2010 14:51:01 -0400 (EDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 99F9ADEE001; Mon, 30 Aug 2010 14:51:00 -0400 (EDT) Message-Id: <9B952A81-2366-49F6-A6CE-029041841525@kumari.net> From: Warren Kumari To: David Conrad In-Reply-To: <707CC634-EDB5-4E11-930F-97342DBEFACD@virtualized.org> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 30 Aug 2010 14:52:46 -0400 References: <4C7B7275.30903@nic.cz> <707CC634-EDB5-4E11-930F-97342DBEFACD@virtualized.org> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] SSHFP (is there a work to do) vs. Securing Last Mile X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 18:52:19 -0000 On Aug 30, 2010, at 2:44 PM, David Conrad wrote: > On Aug 30, 2010, at 1:57 AM, Ond=C5=99ej Sur=C3=BD wrote: >> 3) Secure Last Mile: I think it was already stated here (or on =20 >> other place) that simply trusting AD bit is not sufficient, and =20 >> there is a strong need for securing last mile. Could it be a =20 >> validating resolver on localhost (but it's not secure on multi-user =20= >> machine). > > I'd imagine that if you can't trust your resolver on your local =20 > machine (multi-user or not), you have bigger problems than the risks =20= > associated with DNS response corruption. > >> Could it be IPSec (but this is probably valid only in strictly =20 >> controlled environment). Could be SIG(0) to your resolver? > > There's TSIG too. No, no there isn't. Here is where I go into my standard rant about the =20= fact that standard stub resolvers don't support either of these: Standard stub resolvers don't support SIG(0) / TSIG. Every time I want =20= to do this, someone says "Yeah, it's super easy, you setup the server =20= like then, on the client, you edit /etc/resolv.conf and =20 enter.... erm.... weeeeellll.... gimma a sec... bugger..." Sorry, but yes, I *do* feel better now.... W > Basically, it is any way you can establish a secure channel to the =20 > trusted resolver. Since establishing a secure channel over the =20 > Internet is generally harder than doing so on the local machine, =20 > I've argued that the right place for a validating resolver is on the =20= > local host (and you also have a better chance of getting access to =20 > logs to figure out why stuff fails when those logs are on the local =20= > machine). > >> Hence I don't think that there is a much work to do for SSH since =20 >> the work there is finished (maybe couple of BCP with =20 >> recommendations how to use it), > > I'd agree. > >> but there is a big piece of work on securing the last mile, which =20 >> will probably need a changed APIs in the system libraries in the =20 >> long run, and application stub resolvers in the short run. > > Personally, I've felt pretty much all of the current APIs are =20 > fundamentally broken, e.g., encouraging folks to make assumptions =20 > like data associated with names never change (or IP addresses =20 > associated with end points never change or IP addresses have =20 > particular structure, etc.) for the lifetime of the application. We =20= > could probably come up with some hacks to bandaid over the sucking =20 > chest wound that is the current API model, but it is a big swamp to =20= > drain and I suspect doing it right would be a bit beyond the scope =20 > of the potential working group being discussed here. > > Regards, > -drc > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Credo quia absurdum est. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54283A6814 for ; Mon, 30 Aug 2010 11:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=-1.334, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG1yYh-7cmgm for ; Mon, 30 Aug 2010 11:43:47 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id B0E8D3A699E for ; Mon, 30 Aug 2010 11:43:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 04230DF5ECF; Mon, 30 Aug 2010 11:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2LoLTgIY9MP; Mon, 30 Aug 2010 11:44:16 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id DE4BCDF5EB6; Mon, 30 Aug 2010 11:44:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: David Conrad In-Reply-To: <4C7B7275.30903@nic.cz> Date: Mon, 30 Aug 2010 11:44:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <707CC634-EDB5-4E11-930F-97342DBEFACD@virtualized.org> References: <4C7B7275.30903@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] SSHFP (is there a work to do) vs. Securing Last Mile X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 18:43:48 -0000 On Aug 30, 2010, at 1:57 AM, Ond=C5=99ej Sur=C3=BD wrote: > 3) Secure Last Mile: I think it was already stated here (or on other = place) that simply trusting AD bit is not sufficient, and there is a = strong need for securing last mile. Could it be a validating resolver = on localhost (but it's not secure on multi-user machine). =20 I'd imagine that if you can't trust your resolver on your local machine = (multi-user or not), you have bigger problems than the risks associated = with DNS response corruption. > Could it be IPSec (but this is probably valid only in strictly = controlled environment). Could be SIG(0) to your resolver? There's TSIG too. Basically, it is any way you can establish a secure = channel to the trusted resolver. Since establishing a secure channel = over the Internet is generally harder than doing so on the local = machine, I've argued that the right place for a validating resolver is = on the local host (and you also have a better chance of getting access = to logs to figure out why stuff fails when those logs are on the local = machine).=20 > Hence I don't think that there is a much work to do for SSH since the = work there is finished (maybe couple of BCP with recommendations how to = use it), I'd agree. > but there is a big piece of work on securing the last mile, which will = probably need a changed APIs in the system libraries in the long run, = and application stub resolvers in the short run. Personally, I've felt pretty much all of the current APIs are = fundamentally broken, e.g., encouraging folks to make assumptions like = data associated with names never change (or IP addresses associated with = end points never change or IP addresses have particular structure, etc.) = for the lifetime of the application. We could probably come up with some = hacks to bandaid over the sucking chest wound that is the current API = model, but it is a big swamp to drain and I suspect doing it right would = be a bit beyond the scope of the potential working group being discussed = here. Regards, -drc Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55D983A679F for ; Mon, 30 Aug 2010 01:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[AWL=-0.921, BAYES_50=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjh2kAk0PcsS for ; Mon, 30 Aug 2010 01:56:57 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id D30AC3A67C2 for ; Mon, 30 Aug 2010 01:56:56 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 290C2734214 for ; Mon, 30 Aug 2010 10:57:25 +0200 (CEST) Message-ID: <4C7B7275.30903@nic.cz> Date: Mon, 30 Aug 2010 10:57:25 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [keyassure] SSHFP (is there a work to do) vs. Securing Last Mile X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 08:56:58 -0000 Hi, I was convinced by Phillip that the charter should be as open-minded as possible, even though the original idea was to include just TLS. Anyway I would like to ask you, if you think about adding SSH(FP) to our charter to do a little homework and try using SSHFP with OpenSSH and then write down what's missing from SSHFP. Ie. what will the future work of this group look like on that field. I have used SSHFP in the past and there are two minor and one bigger problem: Minor: 1) openssh server: the setup - you need to run sshfp utility and put the result into the DNS -> some kind of help from OpenSSH would be great - at least print the SSHFP records by default 2) openssh client: you have to enable SSHFP validation by hand, because default value of VerifyHostKeyDNS is "no". Bigger: 3) Secure Last Mile: I think it was already stated here (or on other place) that simply trusting AD bit is not sufficient, and there is a strong need for securing last mile. Could it be a validating resolver on localhost (but it's not secure on multi-user machine). Could it be IPSec (but this is probably valid only in strictly controlled environment). Could be SIG(0) to your resolver? Hence I don't think that there is a much work to do for SSH since the work there is finished (maybe couple of BCP with recommendations how to use it), but there is a big piece of work on securing the last mile, which will probably need a changed APIs in the system libraries in the long run, and application stub resolvers in the short run. Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6116E3A6868 for ; Sun, 29 Aug 2010 13:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.251 X-Spam-Level: X-Spam-Status: No, score=-106.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hpF8F9Lj+GD for ; Sun, 29 Aug 2010 13:30:25 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 1D28C3A6405 for ; Sun, 29 Aug 2010 13:30:25 -0700 (PDT) Received: from US-DOUGLASO-MB.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 517D3A9447A for ; Sun, 29 Aug 2010 20:30:54 +0000 (UTC) Message-ID: <4C7AC37E.6070701@mail-abuse.org> Date: Sun, 29 Aug 2010 13:30:54 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <4C76EE04.1020905@mail-abuse.org> <20100827142523.GB22108@shinkuro.com> In-Reply-To: <20100827142523.GB22108@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2010 20:30:26 -0000 On 8/27/10 7:25 AM, Andrew Sullivan wrote: > On Thu, Aug 26, 2010 at 03:43:16PM -0700, Douglas Otis wrote: >> For cases where clients do not exchange domain names, reverse DNS could >> be utilized to authenticate clients. > Except, of course, that you can't really rely on the reverse tree > being managed. This was not expressing any optimism for reverse DNS, especially with IPv6. Nor for that matter, that IPv6 addresses offer suitable identifiers for clients either. However, a transition toward the use of domains can avoid some of the complexities imposed by an IPv6 environment. Providing conventions that enable opportunistic use of reverse DNS with IPv4 addresses might help to accelerate this transition. -Doug Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D4E3A686D for ; Sun, 29 Aug 2010 12:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.959 X-Spam-Level: X-Spam-Status: No, score=-100.959 tagged_above=-999 required=5 tests=[AWL=-1.438, BAYES_20=-0.74, DATE_IN_PAST_24_48=1.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUX6VM7ajcUh for ; Sun, 29 Aug 2010 12:20:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9EA753A6839 for ; Sun, 29 Aug 2010 12:20:34 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39636 helo=[192.168.1.12]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OpnRB-0004lo-N1; Sun, 29 Aug 2010 15:21:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100827173418.GD12736@vacation.karoshi.com.> References: <20100827173418.GD12736@vacation.karoshi.com.> Date: Fri, 27 Aug 2010 17:54:04 -0400 To: bmanning@vacation.karoshi.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] two vs multi X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2010 19:20:35 -0000 At 5:34 PM +0000 8/27/10, bmanning@vacation.karoshi.com wrote: >One presumes that (a) validating the DNS delegation chain, and then finding at >the end of that validation, (b) a crypto-bundle of goodness is the functional >equivalent of what is known as "two-factor" authentication. > > >So if One validates (a) the forward delegation chain, (b) the >reverse delegation >chain, and finds (c) the _same_ crypto-bundle of goodness at the end of each >validation chain, would this be the functional equivalent of "Multi-factor" >authentication? not based on the common uses of this term. Usually multi-factor implies use of different technologies to authenticate (a person), not multiple uses of the same technology managed by different entities. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5EA53A68E6 for ; Fri, 27 Aug 2010 15:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.957 X-Spam-Level: X-Spam-Status: No, score=-101.957 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iowUZEdGkBv for ; Fri, 27 Aug 2010 15:31:35 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id B8D1C3A6894 for ; Fri, 27 Aug 2010 15:31:34 -0700 (PDT) Received: (qmail 22485 invoked by uid 0); 27 Aug 2010 22:32:06 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 27 Aug 2010 22:32: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=TO+RHvgAV1GQFD+bkRo9HDGYh5BSr70DvH5F3s2MZAt/PxrMTlwfPTW837bBwNBl0yzqLIZq7v2GgvF36Dk8xR2qB1evUK7LLHQq8k8CzVZCTn/H7Zngpn8Uyb46RI9C; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.205]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Op7Sw-0007ul-23 for keyassure@ietf.org; Fri, 27 Aug 2010 16:32:06 -0600 Message-ID: <4C783CE5.1030308@KingsMountain.com> Date: Fri, 27 Aug 2010 15:32:05 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: keyassure@ietf.org 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: [keyassure] Charter round 3 & KeyAssure Wiki X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 22:31:35 -0000 > I think there's still legitimate debate over whether certs or keys are > ideal, and at this stage I'd rather leave it open-ended. +1 (at least ;) =JeffH Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E833A687E for ; Fri, 27 Aug 2010 15:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQBkk1z6DSJb for ; Fri, 27 Aug 2010 15:12:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C3CF03A687B for ; Fri, 27 Aug 2010 15:12:59 -0700 (PDT) Received: from [128.89.253.212] (port=63213 helo=[172.27.16.50]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Op7Av-00033u-LG; Fri, 27 Aug 2010 18:13:29 -0400 Message-Id: <8F24C8CF-EF6D-4AD4-8634-E0F3BC1F1EFA@bbn.com> From: "Richard L. Barnes" To: Warren Kumari In-Reply-To: <0FB74CB6-991B-42F5-AAA0-19A09DEFC87A@kumari.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 27 Aug 2010 18:13:29 -0400 References: <4C77D697.30809@nic.cz> <87tymggc3g.fsf@mocca.josefsson.org> <0FB74CB6-991B-42F5-AAA0-19A09DEFC87A@kumari.net> X-Mailer: Apple Mail (2.936) Cc: Stephen Schultze , keyassure@ietf.org Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 22:13:01 -0000 +3.25 On Aug 27, 2010, at 4:08 PM, Warren Kumari wrote: > > On Aug 27, 2010, at 3:49 PM, Stephen Schultze wrote: > >> I think there's still legitimate debate over whether certs or keys >> are ideal, and at this stage I'd rather leave it open-ended. >> > > > +11 3/4 > > W > >> On Aug 27, 2010, at 2:11 PM, Simon Josefsson wrote: >>> For example, I propose that we qualify the "cryptographic >>> material" to >>> be authenticated to be PKIX certificates and OpenPGP keys. Are >>> there >>> other formats that are an active use? There is SPKI, but we need >>> some >>> SPKI experts to participate in the discussion to make sure we end up >>> with something useful. SSH keys have been discussed. I volunteer >>> to >>> review OpenPGP related parts, I'm less concerned about getting good >>> enough review on the PKIX part. >> >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > -- > American Non-Sequitur Society; > we don't make sense, but we do like pizza! > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D2B3A68DA for ; Fri, 27 Aug 2010 14:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7J9KVecx3ty for ; Fri, 27 Aug 2010 14:16:18 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 302B03A6828 for ; Fri, 27 Aug 2010 14:16:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=fjkDe+RHful6Mc4NXi1T/za0RBOYdn6FBR/lBtFtBZdLCcf+C+/SGTzqlALqFb4T; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.37] (helo=elwamui-karabash.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Op6He-0006vY-I5; Fri, 27 Aug 2010 17:16:22 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 27 Aug 2010 17:16:21 -0400 Message-ID: <24855804.1282943782591.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Date: Fri, 27 Aug 2010 16:16:21 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Phillip Hallam-Baker Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068874a59386e92c5267e3d2da69bcd43369350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.37 Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 21:16:20 -0000 Phillip and all, -----Original Message----- >From: Phillip Hallam-Baker >Sent: Aug 27, 2010 2:37 PM >To: "Jeffrey A. Williams" >Cc: Simon Josefsson , Ond=C5=99ej Sur=C3=BD , keyassure@ietf.org >Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki > >The approach that leads to fewest arguments is usually to write a >charter that is agnostic on the issue of format in the text but only >commits to produce a deliverable for the specific formats that are >necessary to make it work. Yes of course. > >If anyone wants to propose a spec for additional formats, they can, >but only if they can show that there are sufficient people to do the >work and sufficient people in the target community to vet the work. Problem here is in the vetting. Out of the box thinking and than product result may not have the necessary folks in the target community to do a proper vetting, at least not early on. > > >So for example in KEYPROV we started with an assumption that we were >going to write a protocol in XML only. But the charter was agnostic on >that issue and we later had a proposal to shadow the XML spec with an >ASN.1 spec which is a perfectly justifiable approach. The fact that >the draft in question is written by the IETF chair and one of the >Security ADs is (mostly) besides the point. Good example point. > > >2010/8/27 Jeffrey A. Williams : >> Simon and all, >> >> =C2=A0For a start on SPKI, one might want to review >> the information at http://datatracker.ietf.org/doc/search/ >> Currently there is no IETF WG for SPKI. >> >> >> -----Original Message----- >>>From: Simon Josefsson >>>Sent: Aug 27, 2010 1:11 PM >>>To: Ond=C5=99ej Sur=C3=BD >>>Cc: keyassure@ietf.org >>>Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki >>> >>>Thanks Ond=C5=99ej, it looks like a good starting point. =C2=A0I believe= we need >>>to qualify it with references to existing work and technologies though. >>> >>>For example, I propose that we qualify the "cryptographic material" to >>>be authenticated to be PKIX certificates and OpenPGP keys. =C2=A0Are the= re >>>other formats that are an active use? =C2=A0There is SPKI, but we need s= ome >>>SPKI experts to participate in the discussion to make sure we end up >>>with something useful. =C2=A0SSH keys have been discussed. =C2=A0I volun= teer to >>>review OpenPGP related parts, I'm less concerned about getting good >>>enough review on the PKIX part. >>> >>>/Simon >>> >>>Ond=C5=99ej Sur=C3=BD writes: >>> >>>> [I took Warren's original text, added bit from Richard and Nicholas.] >>>> >>>> [I have also created a Wiki page for our charter work at: >>>> =C2=A0http://tools.ietf.org/area/sec/trac/wiki/Keyassure >>>> ] >>>> >>>> Objective: >>>> >>>> Specify mechanisms and techniques that allow Internet applications to >>>> establish cryptographically secured communications by using >>>> information distributed through the DNS for discovering and >>>> authenticating cryptographic material which is associated with a >>>> service located at a domain name >>>> >>>> Problem Statement: >>>> >>>> Entities on the Internet are usually identified by domain names and >>>> forming a cryptographically secured connection to the entity requires >>>> the entity to authenticate its name. =C2=A0For instance, in HTTPS, a s= erver >>>> responding to a query for is expected to >>>> authenticate as "www.example.com". =C2=A0Security protocols such as TL= S and >>>> IPsec accomplish this authentication by allowing an endpoint to prove >>>> ownership of a private key whose corresponding public key is somehow >>>> bound to the name being authenticated. =C2=A0As a pre-requisite for >>>> authentication, then, these protocols require a mechanism for bindings >>>> to be asserted between public keys and domain names. >>>> >>>> DNSSEC provides a mechanism for a domain operator to sign DNS >>>> information directly, using keys that are bound to the domain by the >>>> parent domain; relying parties can continue this chain up to any trust >>>> anchor that they accept. =C2=A0In this way, bindings of keys to domain= s are >>>> asserted not by external entities, but by the entities that operate >>>> the DNS. =C2=A0In addition, this technique inherently limits the scope= of >>>> any given entity to the names in zones he controls. >>>> >>>> This working group will develop mechanisms for domain operators to >>>> present bindings between names within their control and public keys, >>>> in such a way that these bindings can be integrity-protected (and thus >>>> shown to be authentically from the domain operator) using DNSSEC and >>>> used as a basis for authentication in protocols that use domain names >>>> as identifiers. =C2=A0The group may also specify updates or clarificat= ions >>>> to protocols to describe how protocol entities discover and validate >>>> these bindings in the execution of specific applications. >>>> >>>> >>>> Have a nice weekend, >>>_______________________________________________ >>>keyassure mailing list >>>keyassure@ietf.org >>>https://www.ietf.org/mailman/listinfo/keyassure >> >> Regards, >> Jeffrey A. Williams >> Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growin= g, strong!) >> "Obedience of the law is the greatest freedom" - >> =C2=A0 Abraham Lincoln >> >> "Credit should go with the performance of duty and not with what is very >> often the accident of glory" - Theodore Roosevelt >> >> "If the probability be called P; the injury, L; and the burden, B; liabi= lity >> depends upon whether B is less than L multiplied by >> P: i.e., whether B is less than PL." >> United States v. Carroll Towing =C2=A0(159 F.2d 169 [2d Cir. 1947] >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Updated 1/26/04 >> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div.= of >> Information Network Eng. =C2=A0INEG. INC. >> ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom= .com >> Phone: 214-244-4827 >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >> > > > >--=20 >Website: http://hallambaker.com/ Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, = strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liabilit= y depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.co= m Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067393A6828 for ; Fri, 27 Aug 2010 14:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[AWL=1.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 422bYPDdwbYk for ; Fri, 27 Aug 2010 14:10:23 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id A8F7B3A68DA for ; Fri, 27 Aug 2010 14:10:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=DV5HWlWVGmnZigh2YbAauctlzbRutxxaYFwHWioaR5Fv3YGY/bLYZHSC2WVGtTxz; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.37] (helo=elwamui-karabash.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Op6Bg-0006WU-L9; Fri, 27 Aug 2010 17:10:12 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 27 Aug 2010 17:10:12 -0400 Message-ID: <7070010.1282943412702.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Date: Fri, 27 Aug 2010 16:10:12 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: John Gilmore , Stephen Schultze Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688bade47b46569a9a01a71b9f112702205350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.37 Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 21:10:42 -0000 John and all, I for one fully agree with John here. -----Original Message----- >From: John Gilmore >Sent: Aug 27, 2010 3:26 PM >To: Stephen Schultze >Cc: keyassure@ietf.org >Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki > >> I think there's still legitimate debate over whether certs or keys are >> ideal, and at this stage I'd rather leave it open-ended. > >It is absolutely clear that this charter should not require the use >of X.509 certificates for any purpose. > >Those who like ambiguity and error are free to use them, and we may >even produce some RFCs that standardize that ambiguity and error. >Those who wish to avoid those outcomes should be able to follow >alternative paths. > > John >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC163A687B for ; Fri, 27 Aug 2010 13:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.206 X-Spam-Level: * X-Spam-Status: No, score=1.206 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOYnOeXXmn98 for ; Fri, 27 Aug 2010 13:25:49 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by core3.amsl.com (Postfix) with ESMTP id B19AB3A67F4 for ; Fri, 27 Aug 2010 13:25:49 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id o7RKQJxv001993; Fri, 27 Aug 2010 13:26:19 -0700 Message-Id: <201008272026.o7RKQJxv001993@new.toad.com> To: Stephen Schultze In-reply-to: References: <4C77D697.30809@nic.cz> <87tymggc3g.fsf@mocca.josefsson.org> Comments: In-reply-to Stephen Schultze message dated "Fri, 27 Aug 2010 15:49:52 -0400." Date: Fri, 27 Aug 2010 13:26:19 -0700 From: John Gilmore Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 20:25:50 -0000 > I think there's still legitimate debate over whether certs or keys are > ideal, and at this stage I'd rather leave it open-ended. It is absolutely clear that this charter should not require the use of X.509 certificates for any purpose. Those who like ambiguity and error are free to use them, and we may even produce some RFCs that standardize that ambiguity and error. Those who wish to avoid those outcomes should be able to follow alternative paths. John Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25B83A687F for ; Fri, 27 Aug 2010 13:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.294 X-Spam-Level: X-Spam-Status: No, score=-102.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8BcL6DqyTwF for ; Fri, 27 Aug 2010 13:08:09 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id E7A243A687E for ; Fri, 27 Aug 2010 13:08:08 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id BBECB2284A1D; Fri, 27 Aug 2010 16:06:59 -0400 (EDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id E94172284974; Fri, 27 Aug 2010 16:06:58 -0400 (EDT) Message-Id: <0FB74CB6-991B-42F5-AAA0-19A09DEFC87A@kumari.net> From: Warren Kumari To: Stephen Schultze In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 27 Aug 2010 16:08:39 -0400 References: <4C77D697.30809@nic.cz> <87tymggc3g.fsf@mocca.josefsson.org> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 20:08:10 -0000 On Aug 27, 2010, at 3:49 PM, Stephen Schultze wrote: > I think there's still legitimate debate over whether certs or keys > are ideal, and at this stage I'd rather leave it open-ended. > +11 3/4 W > On Aug 27, 2010, at 2:11 PM, Simon Josefsson wrote: >> For example, I propose that we qualify the "cryptographic material" >> to >> be authenticated to be PKIX certificates and OpenPGP keys. Are there >> other formats that are an active use? There is SPKI, but we need >> some >> SPKI experts to participate in the discussion to make sure we end up >> with something useful. SSH keys have been discussed. I volunteer to >> review OpenPGP related parts, I'm less concerned about getting good >> enough review on the PKIX part. > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure -- American Non-Sequitur Society; we don't make sense, but we do like pizza! Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590EB3A689E for ; Fri, 27 Aug 2010 12:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.033 X-Spam-Level: X-Spam-Status: No, score=-6.033 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH4Hl-fn-KOl for ; Fri, 27 Aug 2010 12:49:21 -0700 (PDT) Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id 0B3423A6879 for ; Fri, 27 Aug 2010 12:49:20 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id o7RJnq2V007810 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 27 Aug 2010 15:49:52 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7RJnqpF022891 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 27 Aug 2010 15:49:52 -0400 (EDT) Message-Id: From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: <87tymggc3g.fsf@mocca.josefsson.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 27 Aug 2010 15:49:52 -0400 References: <4C77D697.30809@nic.cz> <87tymggc3g.fsf@mocca.josefsson.org> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6087 signatures=646243 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008270163 Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 19:49:22 -0000 I think there's still legitimate debate over whether certs or keys are ideal, and at this stage I'd rather leave it open-ended. On Aug 27, 2010, at 2:11 PM, Simon Josefsson wrote: > For example, I propose that we qualify the "cryptographic material" to > be authenticated to be PKIX certificates and OpenPGP keys. Are there > other formats that are an active use? There is SPKI, but we need some > SPKI experts to participate in the discussion to make sure we end up > with something useful. SSH keys have been discussed. I volunteer to > review OpenPGP related parts, I'm less concerned about getting good > enough review on the PKIX part. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF543A6952 for ; Fri, 27 Aug 2010 12:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EMm9lUcev6s for ; Fri, 27 Aug 2010 12:36:55 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 147053A68DA for ; Fri, 27 Aug 2010 12:36:55 -0700 (PDT) Received: by iwn3 with SMTP id 3so3131371iwn.31 for ; Fri, 27 Aug 2010 12:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cOffVQ+Wr/JRXtxs5NRxQRx2dFTbtywmjnwQ4bXkbXc=; b=XMq/kMdBR8GmRyVymsI09QSRGDO0bEu0MVu8I+Z6ESVVxj7nvpZ5TS0Flt0dh6TGIc 9N8PQtdXA7oMndI+Om/i4JzdCWgsZZV/f20snu53iIPOSUb4aYc8IiFn/aygtlCugnh5 W4kQt8ezMidjP8e+wLzhY53JJzXJ+jRL0s1BQ= 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:content-transfer-encoding; b=PwQPX08vu/vldrq2CY1A66DPiJqj9LtGKI4YjaZEyS5lwbY9hVT9pEcj+m7BryZ7q7 6AJZ1oZulcINWF65ogTnCWuAjOyMRuTZSop8uqOIleRAwD+2LdWMK2ibVkoNlPbYZeAE apM3eIEDRoeTyj5sb4Ssi0bAhAT4boyzy5kM4= MIME-Version: 1.0 Received: by 10.231.33.131 with SMTP id h3mr1486950ibd.148.1282937846747; Fri, 27 Aug 2010 12:37:26 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Fri, 27 Aug 2010 12:37:26 -0700 (PDT) In-Reply-To: <21921595.1282934020796.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> References: <21921595.1282934020796.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Date: Fri, 27 Aug 2010 15:37:26 -0400 Message-ID: From: Phillip Hallam-Baker To: "Jeffrey A. Williams" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 19:37:00 -0000 The approach that leads to fewest arguments is usually to write a charter that is agnostic on the issue of format in the text but only commits to produce a deliverable for the specific formats that are necessary to make it work. If anyone wants to propose a spec for additional formats, they can, but only if they can show that there are sufficient people to do the work and sufficient people in the target community to vet the work. So for example in KEYPROV we started with an assumption that we were going to write a protocol in XML only. But the charter was agnostic on that issue and we later had a proposal to shadow the XML spec with an ASN.1 spec which is a perfectly justifiable approach. The fact that the draft in question is written by the IETF chair and one of the Security ADs is (mostly) besides the point. 2010/8/27 Jeffrey A. Williams : > Simon and all, > > =C2=A0For a start on SPKI, one might want to review > the information at http://datatracker.ietf.org/doc/search/ > Currently there is no IETF WG for SPKI. > > > -----Original Message----- >>From: Simon Josefsson >>Sent: Aug 27, 2010 1:11 PM >>To: Ond=C5=99ej Sur=C3=BD >>Cc: keyassure@ietf.org >>Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki >> >>Thanks Ond=C5=99ej, it looks like a good starting point. =C2=A0I believe = we need >>to qualify it with references to existing work and technologies though. >> >>For example, I propose that we qualify the "cryptographic material" to >>be authenticated to be PKIX certificates and OpenPGP keys. =C2=A0Are ther= e >>other formats that are an active use? =C2=A0There is SPKI, but we need so= me >>SPKI experts to participate in the discussion to make sure we end up >>with something useful. =C2=A0SSH keys have been discussed. =C2=A0I volunt= eer to >>review OpenPGP related parts, I'm less concerned about getting good >>enough review on the PKIX part. >> >>/Simon >> >>Ond=C5=99ej Sur=C3=BD writes: >> >>> [I took Warren's original text, added bit from Richard and Nicholas.] >>> >>> [I have also created a Wiki page for our charter work at: >>> =C2=A0http://tools.ietf.org/area/sec/trac/wiki/Keyassure >>> ] >>> >>> Objective: >>> >>> Specify mechanisms and techniques that allow Internet applications to >>> establish cryptographically secured communications by using >>> information distributed through the DNS for discovering and >>> authenticating cryptographic material which is associated with a >>> service located at a domain name >>> >>> Problem Statement: >>> >>> Entities on the Internet are usually identified by domain names and >>> forming a cryptographically secured connection to the entity requires >>> the entity to authenticate its name. =C2=A0For instance, in HTTPS, a se= rver >>> responding to a query for is expected to >>> authenticate as "www.example.com". =C2=A0Security protocols such as TLS= and >>> IPsec accomplish this authentication by allowing an endpoint to prove >>> ownership of a private key whose corresponding public key is somehow >>> bound to the name being authenticated. =C2=A0As a pre-requisite for >>> authentication, then, these protocols require a mechanism for bindings >>> to be asserted between public keys and domain names. >>> >>> DNSSEC provides a mechanism for a domain operator to sign DNS >>> information directly, using keys that are bound to the domain by the >>> parent domain; relying parties can continue this chain up to any trust >>> anchor that they accept. =C2=A0In this way, bindings of keys to domains= are >>> asserted not by external entities, but by the entities that operate >>> the DNS. =C2=A0In addition, this technique inherently limits the scope = of >>> any given entity to the names in zones he controls. >>> >>> This working group will develop mechanisms for domain operators to >>> present bindings between names within their control and public keys, >>> in such a way that these bindings can be integrity-protected (and thus >>> shown to be authentically from the domain operator) using DNSSEC and >>> used as a basis for authentication in protocols that use domain names >>> as identifiers. =C2=A0The group may also specify updates or clarificati= ons >>> to protocols to describe how protocol entities discover and validate >>> these bindings in the execution of specific applications. >>> >>> >>> Have a nice weekend, >>_______________________________________________ >>keyassure mailing list >>keyassure@ietf.org >>https://www.ietf.org/mailman/listinfo/keyassure > > Regards, > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing= , strong!) > "Obedience of the law is the greatest freedom" - > =C2=A0 Abraham Lincoln > > "Credit should go with the performance of duty and not with what is very > often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; liabil= ity > depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing =C2=A0(159 F.2d 169 [2d Cir. 1947] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. = of > Information Network Eng. =C2=A0INEG. INC. > ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.= com > Phone: 214-244-4827 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56ACA3A6AB9 for ; Fri, 27 Aug 2010 11:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcO6V--x0vHq for ; Fri, 27 Aug 2010 11:58:25 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 1217E3A6A76 for ; Fri, 27 Aug 2010 11:58:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=KoCsZQ1joMmyakan4pNTq8GU3o9an/tW6WyLq0Xc4CoRK71/b4SSLDM7XfW3Kp00; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.27] (helo=mswamui-billy.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Op48D-00082b-1Y; Fri, 27 Aug 2010 14:58:29 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 27 Aug 2010 14:58:28 -0400 Message-ID: <7156199.1282935509051.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Date: Fri, 27 Aug 2010 13:58:28 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Andrew Sullivan , keyassure@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606884ed6525ee5613f82478ddb9e15980845350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.27 Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:58:26 -0000 Andrew and all, How true! >:( Too many are not managed or managed properly unfortunately. Some may never be... -----Original Message----- >From: Andrew Sullivan >Sent: Aug 27, 2010 9:25 AM >To: keyassure@ietf.org >Subject: Re: [keyassure] Poking the charter bear.... > >On Thu, Aug 26, 2010 at 03:43:16PM -0700, Douglas Otis wrote: >> For cases where clients do not exchange domain names, reverse DNS could >> be utilized to authenticate clients. > >Except, of course, that you can't really rely on the reverse tree >being managed. > >A > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6E03A6A47 for ; Fri, 27 Aug 2010 11:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6u9p7k63av3r for ; Fri, 27 Aug 2010 11:36:54 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E14973A6A6B for ; Fri, 27 Aug 2010 11:36:53 -0700 (PDT) Received: by iwn3 with SMTP id 3so3091283iwn.31 for ; Fri, 27 Aug 2010 11:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ijk/DsXBm7In/9FvCZfYob4mxMR+FjMhVwaYoL+ki+w=; b=tiZclzurr531pm8nZEJt8pWPdUy1H3SgKvdG6nqrxGIEto/jtJaqFhCCVJMUC2kXpj 2Ukun0iUL/Pg0l24X46szR6wZl2m7MwkMDU8ixU4xCvp/Vn8BVOAZ8E6LqN+imgVX8TQ MaFoxApapjPefsUbNha/owBTJDtLtvglTejnQ= 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:content-transfer-encoding; b=vPLd3COkDXNxJBO2dRqRJDHtTRWxpi6pnvNBBD0ashsCTudYxpk4l4byDAkcgt1nj1 rXRIo+DEJdNFt/FdHQX4P36OVcbO7TMAYLYjmfm+y0i1m2PB6nnaC1RiFRZLQvCdPkEk IegtaIX18O+TeUNGSihSZEj19PEcz5wPzhaK4= MIME-Version: 1.0 Received: by 10.231.152.78 with SMTP id f14mr1539166ibw.60.1282934245260; Fri, 27 Aug 2010 11:37:25 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Fri, 27 Aug 2010 11:37:25 -0700 (PDT) In-Reply-To: References: <20100827173418.GD12736@vacation.karoshi.com.> <87pqx3hqgj.fsf@mocca.josefsson.org> <20100827182818.GF12736@vacation.karoshi.com.> Date: Fri, 27 Aug 2010 14:37:25 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] two vs multi X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:36:57 -0000 I would try to keep clear of the term two factor for anything other than end user authentication and then where the authentication factors are based on different principles (e.g. something known, something carried). The term has been widely abused of late due to the interpretation of the federal reserve regulations requiring 'two factor' that allow for non-two factor schemes. This is machine-machine authentication and only one factor is possible. We could use the phrase multiple trust chain or similar. On Fri, Aug 27, 2010 at 2:30 PM, Paul Hoffman wrote= : > At 6:28 PM +0000 8/27/10, bmanning@vacation.karoshi.com wrote: >>On Fri, Aug 27, 2010 at 08:15:40PM +0200, Simon Josefsson wrote: >>> bmanning@vacation.karoshi.com writes: >>> >>> > One presumes that (a) validating the DNS delegation chain, and then f= inding at >>> > the end of that validation, (b) a crypto-bundle of goodness is the fu= nctional >>> > equivalent of what is known as "two-factor" authentication. >>> >>> I'm confused. =A0Unless I'm misunderstanding you, I wouldn't call what = you >>> describe two-factor authentication at all. =A0To me, two-factor >>> authentication is about client authentication, and each factor has to b= e >>> an independent authentication that is provided by the client. =A0See: >>> http://en.wikipedia.org/wiki/Two-factor_authentication >>> >>> /Simon >> >> >> =A0 =A0 =A0 perhaps i misunderstand. =A0the DNSSEC validation chain as a= factor >> =A0 =A0 =A0 consists of a series of independent folks vouching for each = other. >> >> =A0 =A0 =A0 the second factor is the CERT at the end of the chain, in my= understanding >> =A0 =A0 =A0 of the CERT RR, this is effectively an x509 CERT, which is p= rovided by >> =A0 =A0 =A0 a CA* =A0Thats two distinct, independent sources... neither = of which is >> =A0 =A0 =A0 the client. =A0Right? >> >>* - presuming the same party signing a zone is not also your friendly CA.= .. :) > > I'm with Simon: your description has nothing to do with what is commonly = called two-factor authentication. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E79F3A6AA1 for ; Fri, 27 Aug 2010 11:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLpawKnolrVV for ; Fri, 27 Aug 2010 11:33:50 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id EABC33A6A89 for ; Fri, 27 Aug 2010 11:33:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=ns2BpxM4ST5ZhRLbLnX5Ef2hGZrFFgkvp+BSMHJmkvp3WoUp+IdHflAE9KyVvvAS; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.27] (helo=mswamui-billy.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Op3kR-0001Am-Rh; Fri, 27 Aug 2010 14:33:55 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 27 Aug 2010 14:33:40 -0400 Message-ID: <21921595.1282934020796.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Date: Fri, 27 Aug 2010 13:33:40 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Simon Josefsson , =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606885f40c7f9e187dce851bdddb4692e6fbf350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.27 Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:33:51 -0000 Simon and all, For a start on SPKI, one might want to review the information at http://datatracker.ietf.org/doc/search/ Currently there is no IETF WG for SPKI. -----Original Message----- >From: Simon Josefsson >Sent: Aug 27, 2010 1:11 PM >To: Ond=C5=99ej Sur=C3=BD >Cc: keyassure@ietf.org >Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki > >Thanks Ond=C5=99ej, it looks like a good starting point. I believe we nee= d >to qualify it with references to existing work and technologies though. > >For example, I propose that we qualify the "cryptographic material" to >be authenticated to be PKIX certificates and OpenPGP keys. Are there >other formats that are an active use? There is SPKI, but we need some >SPKI experts to participate in the discussion to make sure we end up >with something useful. SSH keys have been discussed. I volunteer to >review OpenPGP related parts, I'm less concerned about getting good >enough review on the PKIX part. > >/Simon > >Ond=C5=99ej Sur=C3=BD writes: > >> [I took Warren's original text, added bit from Richard and Nicholas.] >> >> [I have also created a Wiki page for our charter work at: >> http://tools.ietf.org/area/sec/trac/wiki/Keyassure >> ] >> >> Objective: >> >> Specify mechanisms and techniques that allow Internet applications to >> establish cryptographically secured communications by using >> information distributed through the DNS for discovering and >> authenticating cryptographic material which is associated with a >> service located at a domain name >> >> Problem Statement: >> >> Entities on the Internet are usually identified by domain names and >> forming a cryptographically secured connection to the entity requires >> the entity to authenticate its name. For instance, in HTTPS, a server >> responding to a query for is expected to >> authenticate as "www.example.com". Security protocols such as TLS and >> IPsec accomplish this authentication by allowing an endpoint to prove >> ownership of a private key whose corresponding public key is somehow >> bound to the name being authenticated. As a pre-requisite for >> authentication, then, these protocols require a mechanism for bindings >> to be asserted between public keys and domain names. >> >> DNSSEC provides a mechanism for a domain operator to sign DNS >> information directly, using keys that are bound to the domain by the >> parent domain; relying parties can continue this chain up to any trust >> anchor that they accept. In this way, bindings of keys to domains are >> asserted not by external entities, but by the entities that operate >> the DNS. In addition, this technique inherently limits the scope of >> any given entity to the names in zones he controls. >> >> This working group will develop mechanisms for domain operators to >> present bindings between names within their control and public keys, >> in such a way that these bindings can be integrity-protected (and thus >> shown to be authentically from the domain operator) using DNSSEC and >> used as a basis for authentication in protocols that use domain names >> as identifiers. The group may also specify updates or clarifications >> to protocols to describe how protocol entities discover and validate >> these bindings in the execution of specific applications. >> >> >> Have a nice weekend, >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, = strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liabilit= y depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.co= m Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FAEA3A68B9 for ; Fri, 27 Aug 2010 11:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.058 X-Spam-Level: X-Spam-Status: No, score=-101.058 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+nUSLefhenl for ; Fri, 27 Aug 2010 11:29:44 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9A5D23A69E2 for ; Fri, 27 Aug 2010 11:29:44 -0700 (PDT) Received: from [10.20.30.158] (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 o7RIUFUg011013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Aug 2010 11:30:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100827182818.GF12736@vacation.karoshi.com.> References: <20100827173418.GD12736@vacation.karoshi.com.> <87pqx3hqgj.fsf@mocca.josefsson.org> <20100827182818.GF12736@vacation.karoshi.com.> Date: Fri, 27 Aug 2010 11:30:13 -0700 To: bmanning@vacation.karoshi.com, Simon Josefsson From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] two vs multi X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:29:45 -0000 At 6:28 PM +0000 8/27/10, bmanning@vacation.karoshi.com wrote: >On Fri, Aug 27, 2010 at 08:15:40PM +0200, Simon Josefsson wrote: >> bmanning@vacation.karoshi.com writes: >> >> > One presumes that (a) validating the DNS delegation chain, and then finding at >> > the end of that validation, (b) a crypto-bundle of goodness is the functional >> > equivalent of what is known as "two-factor" authentication. >> >> I'm confused. Unless I'm misunderstanding you, I wouldn't call what you >> describe two-factor authentication at all. To me, two-factor >> authentication is about client authentication, and each factor has to be >> an independent authentication that is provided by the client. See: >> http://en.wikipedia.org/wiki/Two-factor_authentication >> >> /Simon > > > perhaps i misunderstand. the DNSSEC validation chain as a factor > consists of a series of independent folks vouching for each other. > > the second factor is the CERT at the end of the chain, in my understanding > of the CERT RR, this is effectively an x509 CERT, which is provided by > a CA* Thats two distinct, independent sources... neither of which is > the client. Right? > >* - presuming the same party signing a zone is not also your friendly CA... :) I'm with Simon: your description has nothing to do with what is commonly called two-factor authentication. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547763A69E2 for ; Fri, 27 Aug 2010 11:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJXKGmtwpb5n for ; Fri, 27 Aug 2010 11:28:00 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 258033A68C0 for ; Fri, 27 Aug 2010 11:28:00 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o7RISJA1013106; Fri, 27 Aug 2010 18:28:20 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o7RISINw013105; Fri, 27 Aug 2010 18:28:18 GMT Date: Fri, 27 Aug 2010 18:28:18 +0000 From: bmanning@vacation.karoshi.com To: Simon Josefsson Message-ID: <20100827182818.GF12736@vacation.karoshi.com.> References: <20100827173418.GD12736@vacation.karoshi.com.> <87pqx3hqgj.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pqx3hqgj.fsf@mocca.josefsson.org> User-Agent: Mutt/1.4.1i Cc: keyassure@ietf.org Subject: Re: [keyassure] two vs multi X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:28:01 -0000 On Fri, Aug 27, 2010 at 08:15:40PM +0200, Simon Josefsson wrote: > bmanning@vacation.karoshi.com writes: > > > One presumes that (a) validating the DNS delegation chain, and then finding at > > the end of that validation, (b) a crypto-bundle of goodness is the functional > > equivalent of what is known as "two-factor" authentication. > > I'm confused. Unless I'm misunderstanding you, I wouldn't call what you > describe two-factor authentication at all. To me, two-factor > authentication is about client authentication, and each factor has to be > an independent authentication that is provided by the client. See: > http://en.wikipedia.org/wiki/Two-factor_authentication > > /Simon perhaps i misunderstand. the DNSSEC validation chain as a factor consists of a series of independent folks vouching for each other. the second factor is the CERT at the end of the chain, in my understanding of the CERT RR, this is effectively an x509 CERT, which is provided by a CA* Thats two distinct, independent sources... neither of which is the client. Right? * - presuming the same party signing a zone is not also your friendly CA... :) --bill Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC823A6A1B for ; Fri, 27 Aug 2010 11:15:29 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY5oR5b65Zdr for ; Fri, 27 Aug 2010 11:15:27 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 73BE23A69EF for ; Fri, 27 Aug 2010 11:15:27 -0700 (PDT) Received: from mocca (94.191.150.218.bredband.tre.se [94.191.150.218]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7RIFf79004544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Aug 2010 20:15:46 +0200 From: Simon Josefsson To: bmanning@vacation.karoshi.com References: <20100827173418.GD12736@vacation.karoshi.com.> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100827:bmanning@vacation.karoshi.com::kZEip439krd1X8aB:3b2E X-Hashcash: 1:22:100827:keyassure@ietf.org::Mfpzs4N/1yPz8IbO:kS/Z Date: Fri, 27 Aug 2010 20:15:40 +0200 In-Reply-To: <20100827173418.GD12736@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Fri, 27 Aug 2010 17:34:18 +0000") Message-ID: <87pqx3hqgj.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] two vs multi X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:15:29 -0000 bmanning@vacation.karoshi.com writes: > One presumes that (a) validating the DNS delegation chain, and then finding at > the end of that validation, (b) a crypto-bundle of goodness is the functional > equivalent of what is known as "two-factor" authentication. I'm confused. Unless I'm misunderstanding you, I wouldn't call what you describe two-factor authentication at all. To me, two-factor authentication is about client authentication, and each factor has to be an independent authentication that is provided by the client. See: http://en.wikipedia.org/wiki/Two-factor_authentication /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 103963A6A10 for ; Fri, 27 Aug 2010 11:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVpHlO1b2wzZ for ; Fri, 27 Aug 2010 11:11:06 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id D8FAA3A69DC for ; Fri, 27 Aug 2010 11:11:03 -0700 (PDT) Received: from mocca (94.191.150.218.bredband.tre.se [94.191.150.218]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7RIBJnj004266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Aug 2010 20:11:26 +0200 From: Simon Josefsson To: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= References: <4C77D697.30809@nic.cz> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100827:keyassure@ietf.org::vDEvD91IO/vniVOe:5j9J X-Hashcash: 1:22:100827:ondrej.sury@nic.cz::jQeKjJIOHh8dw7fH:IYC3 Date: Fri, 27 Aug 2010 20:11:15 +0200 In-Reply-To: <4C77D697.30809@nic.cz> (=?iso-8859-2?Q?=22Ond=F8ej_Sur=FD=22?= =?iso-8859-2?Q?'s?= message of "Fri, 27 Aug 2010 17:15:35 +0200") Message-ID: <87tymggc3g.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter round 3 & KeyAssure Wiki X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:11:10 -0000 Thanks Ond=F8ej, it looks like a good starting point. I believe we need to qualify it with references to existing work and technologies though. For example, I propose that we qualify the "cryptographic material" to be authenticated to be PKIX certificates and OpenPGP keys. Are there other formats that are an active use? There is SPKI, but we need some SPKI experts to participate in the discussion to make sure we end up with something useful. SSH keys have been discussed. I volunteer to review OpenPGP related parts, I'm less concerned about getting good enough review on the PKIX part. /Simon Ond=F8ej Sur=FD writes: > [I took Warren's original text, added bit from Richard and Nicholas.] > > [I have also created a Wiki page for our charter work at: > http://tools.ietf.org/area/sec/trac/wiki/Keyassure > ] > > Objective: > > Specify mechanisms and techniques that allow Internet applications to > establish cryptographically secured communications by using > information distributed through the DNS for discovering and > authenticating cryptographic material which is associated with a > service located at a domain name > > Problem Statement: > > Entities on the Internet are usually identified by domain names and > forming a cryptographically secured connection to the entity requires > the entity to authenticate its name. For instance, in HTTPS, a server > responding to a query for is expected to > authenticate as "www.example.com". Security protocols such as TLS and > IPsec accomplish this authentication by allowing an endpoint to prove > ownership of a private key whose corresponding public key is somehow > bound to the name being authenticated. As a pre-requisite for > authentication, then, these protocols require a mechanism for bindings > to be asserted between public keys and domain names. > > DNSSEC provides a mechanism for a domain operator to sign DNS > information directly, using keys that are bound to the domain by the > parent domain; relying parties can continue this chain up to any trust > anchor that they accept. In this way, bindings of keys to domains are > asserted not by external entities, but by the entities that operate > the DNS. In addition, this technique inherently limits the scope of > any given entity to the names in zones he controls. > > This working group will develop mechanisms for domain operators to > present bindings between names within their control and public keys, > in such a way that these bindings can be integrity-protected (and thus > shown to be authentically from the domain operator) using DNSSEC and > used as a basis for authentication in protocols that use domain names > as identifiers. The group may also specify updates or clarifications > to protocols to describe how protocol entities discover and validate > these bindings in the execution of specific applications. > > > Have a nice weekend, Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295593A6896 for ; Fri, 27 Aug 2010 10:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 357P1xurXrTg for ; Fri, 27 Aug 2010 10:44:31 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 3AE4E3A6843 for ; Fri, 27 Aug 2010 10:44:31 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o7RHiwA1012992; Fri, 27 Aug 2010 17:44:58 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o7RHiw9N012991; Fri, 27 Aug 2010 17:44:58 GMT Date: Fri, 27 Aug 2010 17:44:58 +0000 From: bmanning@vacation.karoshi.com To: keyassure@ietf.org Message-ID: <20100827174458.GE12736@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [keyassure] who vs what X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 17:44:32 -0000 This idea has been alluded to in other threads; there are even a couple of drafts in circulation on one aspect of this idea. It might have even have been the premise of the bar-bof, the ensueing charter and work todate. The idea? That the CERT/DKIM etc RR is targeted at a given app that may or may not be running on a given target. EG - WHAT Is there any value in this? That the CERT is targeted at the given target. EG - WHO I would like to think there is value in crypto certification that a target node is whom it says it is - with other keys/hashes/app-specific crypto as adjuncts to the RRset. In this way, we don't have the "portmanteau" effect of a given crypto bundle identifying both WHO and WHAT. Or am I just being problematic? --bill Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680823A69AA for ; Fri, 27 Aug 2010 10:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hvql9snccMao for ; Fri, 27 Aug 2010 10:33:54 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 947813A68AE for ; Fri, 27 Aug 2010 10:33:51 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o7RHYIA1012961; Fri, 27 Aug 2010 17:34:18 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o7RHYIUb012960; Fri, 27 Aug 2010 17:34:18 GMT Date: Fri, 27 Aug 2010 17:34:18 +0000 From: bmanning@vacation.karoshi.com To: keyassure@ietf.org Message-ID: <20100827173418.GD12736@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [keyassure] two vs multi X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 17:33:55 -0000 One presumes that (a) validating the DNS delegation chain, and then finding at the end of that validation, (b) a crypto-bundle of goodness is the functional equivalent of what is known as "two-factor" authentication. So if One validates (a) the forward delegation chain, (b) the reverse delegation chain, and finds (c) the _same_ crypto-bundle of goodness at the end of each validation chain, would this be the functional equivalent of "Multi-factor" authentication? --bill Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE6F3A6985 for ; Fri, 27 Aug 2010 09:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbcqxJGuGWV2 for ; Fri, 27 Aug 2010 09:48:10 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 78AE63A6843 for ; Fri, 27 Aug 2010 09:48:10 -0700 (PDT) Received: by gwb20 with SMTP id 20so1452546gwb.31 for ; Fri, 27 Aug 2010 09:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vAnhxC5XiZPN5Tm9ltTjgHfAynKRJMVeOnZVl+RJBHw=; b=feHR5GShVBmCjVraxOb1Scu3E3eH6s5d7o1VfIrFfj9HzB0P3OaXJHEoOj04fzObI6 xdYgCl00Dh0LVSp76D2gPWius7LKw2INbU15Df7plIsrjfMZR0wkKOT6imTLlkgP3LcA isywZjzriuq8AB7t4aqjfmCH+26NaZSFt5uxU= 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:content-transfer-encoding; b=qFaJXX25fC8Pnn45V3MZh+WjrOn9KvCQSL+Pm4MMcjW6JPB1Nhs3rrzDCAw/HZMdOT FaoU7q5Tu5vkajMH3G8BznIMkSWgdpSDocHXlJ1AMLqI0zTlLD18jtTo9Nw3thcbpmHZ KnaAsiF0FwCtdrCwUyo5lJYkXEbpfJes4iXIU= MIME-Version: 1.0 Received: by 10.151.63.23 with SMTP id q23mr2197939ybk.133.1282927722379; Fri, 27 Aug 2010 09:48:42 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Fri, 27 Aug 2010 09:48:42 -0700 (PDT) In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEAF235AA11@DEN-MEXMS-001.corp.ebay.com> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <4C76EE04.1020905@mail-abuse.org> <20100827142523.GB22108@shinkuro.com> <20100827163202.GA12736@vacation.karoshi.com.> <5EE049BA3C6538409BBE6F1760F328ABEAF235AA11@DEN-MEXMS-001.corp.ebay.com> Date: Fri, 27 Aug 2010 12:48:42 -0400 Message-ID: From: Phillip Hallam-Baker To: "Steingruebl, Andy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 16:48:12 -0000 The only part of DNS space a party can rely on being well managed is the space that they control. My approach to securing 10.0.0.0/8 would be as follows: 1) Site generates a CERT record for the KSK of its server and installs it on each populated node in their rDNS. 2) Extensions to support use of DNSSEC for key assurance in SSH are extended to allow the KSK key to be added to the trust store as a trust anchor. 3) Generate SSH keys for each host and install them in the forward and reverse DNS. This approach means that the task of managing SSH keys in a large server farm is reduced to managing one key per host on the client to managing one key for the entire site. My ultimate root of trust is always going to be me. I am not going to validate the entire rest of the world personally, I am going to choose intermediaries I trust to do that on my behalf. But I am the only person who is going to do the choosing. As a rule, applications have to prove their value in the Intranet before people feel confident about external deployment. On Fri, Aug 27, 2010 at 12:36 PM, Steingruebl, Andy wrote: >> -----Original Message----- >> From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On >> Behalf Of bmanning@vacation.karoshi.com >> Sent: Friday, August 27, 2010 9:32 AM >> >> =A0 =A0 =A0 the point being, that most folks seem to agree on the charte= r >> =A0 =A0 =A0 being applicable to the entire DNS namespace, not just a por= tion. > > On the one hand I conceptually agree. On the other hand any mechanism is = going to rely on signed data from DNS. =A0Without getting into the argument= s again about what the trust anchors will be, the necessarily restriction i= s still that the DNS space in question must be trust-anchored somehow. > > Yes? > > This means that for those using the DNS root as their trust-anchor, the 1= 92.in-addr.arpa. space can't hold any of this data, right? =A0Or does it no= t mean that? > > - Andy > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D4C3A69E3 for ; Fri, 27 Aug 2010 09:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.595 X-Spam-Level: X-Spam-Status: No, score=-101.595 tagged_above=-999 required=5 tests=[AWL=1.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HySbg9wFQ6Vh for ; Fri, 27 Aug 2010 09:40:07 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 2EDDF3A69DC for ; Fri, 27 Aug 2010 09:40:06 -0700 (PDT) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1A80D1ECB41D for ; Fri, 27 Aug 2010 16:40:38 +0000 (UTC) Date: Fri, 27 Aug 2010 12:40:36 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20100827164036.GD22108@shinkuro.com> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <4C76EE04.1020905@mail-abuse.org> <20100827142523.GB22108@shinkuro.com> <20100827163202.GA12736@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100827163202.GA12736@vacation.karoshi.com.> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 16:40:08 -0000 On Fri, Aug 27, 2010 at 04:32:02PM +0000, bmanning@vacation.karoshi.com wrote: > > and you can rely on the forward tree being managed? You can in fact rely on the forward tree's data pointing to the machine you actually get to when you use the DNS entry, so there's never a doubt about what the answer you're using matches. There's precious little evidence that the reverse tree's data actually corresponds to any state of the network. That said, > the point being, that most folks seem to agree on the charter > being applicable to the entire DNS namespace, not just a portion. my natural assumption any time we talk about an RR is that one automatically has to deal with the entire namespace. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4153A69E9 for ; Fri, 27 Aug 2010 09:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.117 X-Spam-Level: X-Spam-Status: No, score=-5.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0LBZeYYFsx2 for ; Fri, 27 Aug 2010 09:35:40 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id 607123A69E3 for ; Fri, 27 Aug 2010 09:35:40 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=dtdv+CkMDzbz3441sEofaglshFv7G6w8+b+UNeATaGn021heedMjznF6 v7T6pXnJd5vh7rl+hE4hUN+w4GmYfp6QpSRYsR4Z5P/6YXIbxZzesQlSF AFJGQ0eMoD/xHl8; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1282926973; x=1314462973; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20"bmanning@vacation.karoshi.com"=20,=20Andrew=0D=0A=20Sullivan=20|CC:=20"keyassure@ietf.org"=20|Date:=20Fri,=2027=20Aug=202010=2010:36:10=20-0600 |Subject:=20RE:=20[keyassure]=20Poking=20the=20charter=20 bear....|Message-ID:=20<5EE049BA3C6538409BBE6F1760F328ABE AF235AA11@DEN-MEXMS-001.corp.ebay.com>|References:=20<588 F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net>=0D=0A=09<2D 5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com>=0D=0A=09<2010 0825213056.GA19087@shinkuro.com>=0D=0A=09<349A43F8-F507-4 359-AA3F-3E8545EA0C46@icsi.berkeley.edu>=0D=0A=09<4C76EE0 4.1020905@mail-abuse.org>=09<20100827142523.GB22108@shink uro.com>=0D=0A=20<20100827163202.GA12736@vacation.karoshi .com.>|In-Reply-To:=20<20100827163202.GA12736@vacation.ka roshi.com.>|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=ww/Z/ABbzn5+IqZCTDfvLnr8c9qROLiLcCoads+3As8=; b=sKQJQqW1XTc914tSVM8C5jgtGI0SydS1MuYQ4xzDBSSGvdmivkjN1Cw0 rvvg43tMpnukX+W8rJvQhl/usN8HN8sbE1KGey8fDclIxTFFqEVq3/O1u nMjjb/ODYcrHz0F; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.56,279,1280732400"; d="scan'208";a="71915351" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 27 Aug 2010 09:36:12 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Fri, 27 Aug 2010 10:36:11 -0600 From: "Steingruebl, Andy" To: "bmanning@vacation.karoshi.com" , Andrew Sullivan Date: Fri, 27 Aug 2010 10:36:10 -0600 Thread-Topic: [keyassure] Poking the charter bear.... Thread-Index: ActGBWykIdGwPZOzSHak8r3gv5hlyQAACgHA Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEAF235AA11@DEN-MEXMS-001.corp.ebay.com> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <4C76EE04.1020905@mail-abuse.org> <20100827142523.GB22108@shinkuro.com> <20100827163202.GA12736@vacation.karoshi.com.> In-Reply-To: <20100827163202.GA12736@vacation.karoshi.com.> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 16:35:41 -0000 > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On > Behalf Of bmanning@vacation.karoshi.com > Sent: Friday, August 27, 2010 9:32 AM >=20 > the point being, that most folks seem to agree on the charter > being applicable to the entire DNS namespace, not just a portion. On the one hand I conceptually agree. On the other hand any mechanism is go= ing to rely on signed data from DNS. Without getting into the arguments ag= ain about what the trust anchors will be, the necessarily restriction is st= ill that the DNS space in question must be trust-anchored somehow. Yes? This means that for those using the DNS root as their trust-anchor, the 192= .in-addr.arpa. space can't hold any of this data, right? Or does it not me= an that? - Andy Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCDDC3A6852 for ; Fri, 27 Aug 2010 09:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuXX-s88udJG for ; Fri, 27 Aug 2010 09:31:42 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 27A453A682D for ; Fri, 27 Aug 2010 09:31:41 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o7RGW2A1012752; Fri, 27 Aug 2010 16:32:08 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o7RGW2P7012751; Fri, 27 Aug 2010 16:32:02 GMT Date: Fri, 27 Aug 2010 16:32:02 +0000 From: bmanning@vacation.karoshi.com To: Andrew Sullivan Message-ID: <20100827163202.GA12736@vacation.karoshi.com.> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <4C76EE04.1020905@mail-abuse.org> <20100827142523.GB22108@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100827142523.GB22108@shinkuro.com> User-Agent: Mutt/1.4.1i Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 16:31:44 -0000 On Fri, Aug 27, 2010 at 10:25:23AM -0400, Andrew Sullivan wrote: > On Thu, Aug 26, 2010 at 03:43:16PM -0700, Douglas Otis wrote: > > For cases where clients do not exchange domain names, reverse DNS could > > be utilized to authenticate clients. > > Except, of course, that you can't really rely on the reverse tree > being managed. and you can rely on the forward tree being managed? (sorry, don't really want to wander down this path again... debates over how well managed (whatever that means) various parts of the DNS namespace are is fraught w/ (un)considered opinions and spotty emperical data) the point being, that most folks seem to agree on the charter being applicable to the entire DNS namespace, not just a portion. thats all my question was trying to raise. debate on the relative merits of how well any portion of the namespace is "maintained" does not seem germaine to the topic at hand - if it is, please let me know. --bill Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265893A6A0D for ; Fri, 27 Aug 2010 08:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awGhksfB8MsK for ; Fri, 27 Aug 2010 08:22:27 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 8CB6A3A69CA for ; Fri, 27 Aug 2010 08:22:26 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id DF8BC7343AA; Fri, 27 Aug 2010 17:22:57 +0200 (CEST) Message-ID: <4C77D851.6080704@nic.cz> Date: Fri, 27 Aug 2010 17:22:57 +0200 From: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <4C76EE04.1020905@mail-abuse.org> <20100827142523.GB22108@shinkuro.com> <4C77CF97.8040307@nic.cz> <4C77D3AA.7030907@nic.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 15:22:28 -0000 On 27.8.2010 17:14, Phillip Hallam-Baker wrote: > You called a bar BOF, not a BOF. Apologies, my mistake. > That does not mean that you now hold the decision stick on what > should be in or out of a proposed charter. I am just pointing out, that we had a certain idea in our minds when we gathered and created this non-WG mailing list. So far we have two new drafts and both of them are targeting exactly the area why we created this mailing list. > You do not at this point have sanction from an AD. I am not saying I have. I am only talking why we created this mailing list. > But regardless of whether designing to support SSH is in or out of > charter, experience from the SSH proposal is in charter. > > > I suspect that SSH use has not been very extensive given the lack of > an ICANN signed root. I would therefore suggest as an experiment we > look to see if SSH use could be increased by using a CERT record to > declare a local root for a zone and then configure SSH to use that > as its trust anchor. There is lot of stuff which could be covered by a future-to-be WG. But the more stuff we put under our wings the less likely this group will create any useful output. I say let's stay focused on the topic we started with. Ondrej > On Fri, Aug 27, 2010 at 11:03 AM, Ondøej Surý > wrote: >> On 27.8.2010 16:49, Nicholas Weaver wrote: >>> >>> On Aug 27, 2010, at 7:45 AM, Ondøej Surý wrote: >>> >>>> On 27.8.2010 16:42, Phillip Hallam-Baker wrote: >>>>> >>>>> The reason that the reverse tree is not properly managed is >>>>> that doing so is not necessary for most Web applications. >>>>> >>>>> I would see the utility of this approach being for use with >>>>> applications such as SSH and other network management tools >>>>> that are used by the type of people who make sure their >>>>> reverse DNS works should they actually need it. >>>> >>>> May I remind this list, that SSH is out of the scope? And we >>>> already have a existing SSHFP RR. So when you think about >>>> reverse tree, please don't include SSH nor IPSec. >>> >>> Uh, actually SSH IMO, is perfectly in scope. >>> >>> The real scope is not new resource records but new APIs and >>> techniques: You may be able to get the SSHFP RR today, but we >>> need ways for the SSH application to validate that the key is >>> indeed valid, and we need protocol and policy to get reverse >>> lookups to be reliable in this case. >> >> >> Let me rephrase what I said... >> >> The SSH and IPSec was out of scope when we created this mailing >> list, called the BoF and planned the creation of WG. So I still >> think the SSH is out-of-the-scope. And I personally would like to >> keep it that way. >> >> Ondrej -- Ondøej Surý vedoucí výzkumu/Head of R&D department >> ------------------------------------------- CZ.NIC, z.s.p.o. -- >> Laboratoøe CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic >> mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 >> fax:+420.222745112 ------------------------------------------- >> _______________________________________________ keyassure mailing >> list keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >> > > > -- Ondøej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoøe CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0804C3A672E for ; Fri, 27 Aug 2010 08:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.071 X-Spam-Level: X-Spam-Status: No, score=-0.071 tagged_above=-999 required=5 tests=[AWL=-0.971, BAYES_50=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE8aVCxcHhjN for ; Fri, 27 Aug 2010 08:15:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id EDF533A69CA for ; Fri, 27 Aug 2010 08:15:03 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 6BE827343AA for ; Fri, 27 Aug 2010 17:15:35 +0200 (CEST) Message-ID: <4C77D697.30809@nic.cz> Date: Fri, 27 Aug 2010 17:15:35 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [keyassure] Charter round 3 & KeyAssure Wiki X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 15:15:07 -0000 [I took Warren's original text, added bit from Richard and Nicholas.] [I have also created a Wiki page for our charter work at: http://tools.ietf.org/area/sec/trac/wiki/Keyassure ] Objective: Specify mechanisms and techniques that allow Internet applications to establish cryptographically secured communications by using information distributed through the DNS for discovering and authenticating cryptographic material which is associated with a service located at a domain name Problem Statement: Entities on the Internet are usually identified by domain names and forming a cryptographically secured connection to the entity requires the entity to authenticate its name. For instance, in HTTPS, a server responding to a query for is expected to authenticate as "www.example.com". Security protocols such as TLS and IPsec accomplish this authentication by allowing an endpoint to prove ownership of a private key whose corresponding public key is somehow bound to the name being authenticated. As a pre-requisite for authentication, then, these protocols require a mechanism for bindings to be asserted between public keys and domain names. DNSSEC provides a mechanism for a domain operator to sign DNS information directly, using keys that are bound to the domain by the parent domain; relying parties can continue this chain up to any trust anchor that they accept. In this way, bindings of keys to domains are asserted not by external entities, but by the entities that operate the DNS. In addition, this technique inherently limits the scope of any given entity to the names in zones he controls. This working group will develop mechanisms for domain operators to present bindings between names within their control and public keys, in such a way that these bindings can be integrity-protected (and thus shown to be authentically from the domain operator) using DNSSEC and used as a basis for authentication in protocols that use domain names as identifiers. The group may also specify updates or clarifications to protocols to describe how protocol entities discover and validate these bindings in the execution of specific applications. Have a nice weekend, -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A357A3A69CA for ; Fri, 27 Aug 2010 08:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.472 X-Spam-Level: X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtCVa0WVdbRp for ; Fri, 27 Aug 2010 08:13:53 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 8AD603A697B for ; Fri, 27 Aug 2010 08:13:53 -0700 (PDT) Received: by pvg7 with SMTP id 7so1330095pvg.31 for ; Fri, 27 Aug 2010 08:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=t2EOiZWY/B4VNZJnBVFoOlN56hJ3+fkKJMlgHFXV3+s=; b=aj8MEisYx25LyWFLNWFdP5TD97+RfRFS3Nno07Vd/DXLGiDlMcFMbzB5SQSC5gYqYp OA92TX0Kpj5YWiNEK+gN4ocd/H853QrjwdhBSn68LTyK8uWl/6q267KyH59eOTZPg+mV 3hd5ebtmKjwSmm4FmSMi533Ca3wDyaXFgZroE= 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:content-transfer-encoding; b=S3OVxyhJ1+9XkpsaIIkxGVCDT5sKb4NpScXGSAm7pPF/Eq4BQ94cH28f8uybpfbcyE 8qf7aswFLmqAYUmnYuTgCbw+qJvvB+kg/C2E6DVNYL2Ei6cWY7q6ufyUe8y0lBw0kEe2 atOZzihZSCXczApWGP/zZSdy4Tra3w6RIZJGI= MIME-Version: 1.0 Received: by 10.142.44.11 with SMTP id r11mr1370630wfr.108.1282922065697; Fri, 27 Aug 2010 08:14:25 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Fri, 27 Aug 2010 08:14:25 -0700 (PDT) In-Reply-To: <4C77D3AA.7030907@nic.cz> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <4C76EE04.1020905@mail-abuse.org> <20100827142523.GB22108@shinkuro.com> <4C77CF97.8040307@nic.cz> <4C77D3AA.7030907@nic.cz> Date: Fri, 27 Aug 2010 11:14:25 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 15:13:55 -0000 You called a bar BOF, not a BOF. That does not mean that you now hold the decision stick on what should be in or out of a proposed charter. You do not at this point have sanction from an AD. But regardless of whether designing to support SSH is in or out of charter, experience from the SSH proposal is in charter. I suspect that SSH use has not been very extensive given the lack of an ICANN signed root. I would therefore suggest as an experiment we look to see if SSH use could be increased by using a CERT record to declare a local root for a zone and then configure SSH to use that as its trust anchor. On Fri, Aug 27, 2010 at 11:03 AM, Ond=F8ej Sur=FD wrot= e: > On 27.8.2010 16:49, Nicholas Weaver wrote: >> >> On Aug 27, 2010, at 7:45 AM, Ond=F8ej Sur=FD wrote: >> >>> On 27.8.2010 16:42, Phillip Hallam-Baker wrote: >>>> >>>> The reason that the reverse tree is not properly managed is that >>>> doing so is not necessary for most Web applications. >>>> >>>> I would see the utility of this approach being for use with >>>> applications such as SSH and other network management tools that >>>> are used by the type of people who make sure their reverse DNS >>>> works should they actually need it. >>> >>> May I remind this list, that SSH is out of the scope? =A0And we >>> already have a existing SSHFP RR. =A0So when you think about reverse >>> tree, please don't include SSH nor IPSec. >> >> Uh, actually SSH IMO, is perfectly in scope. >> >> The real scope is not new resource records but new APIs and >> techniques: =A0You may be able to get the SSHFP RR today, but we need >> ways for the SSH application to validate that the key is indeed >> valid, and we need protocol and policy to get reverse lookups to be >> reliable in this case. > > > Let me rephrase what I said... > > The SSH and IPSec was out of scope when we created this mailing list, cal= led > the BoF and planned the creation of WG. =A0So I still think the SSH is > out-of-the-scope. =A0And I personally would like to keep it that way. > > Ondrej > -- > =A0Ond=F8ej Sur=FD > =A0vedouc=ED v=FDzkumu/Head of R&D department > =A0------------------------------------------- > =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC > =A0Americka 23, 120 00 Praha 2, Czech Republic > =A0mailto:ondrej.sury@nic.cz =A0 =A0http://nic.cz/ > =A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112 > =A0------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6043A6A80 for ; Fri, 27 Aug 2010 08:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_40=-0.185, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2l-pm7YFFTEn for ; Fri, 27 Aug 2010 08:02:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id D100A3A69CD for ; Fri, 27 Aug 2010 08:02:35 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 504CE7343AA for ; Fri, 27 Aug 2010 17:03:07 +0200 (CEST) Message-ID: <4C77D3AA.7030907@nic.cz> Date: Fri, 27 Aug 2010 17:03:06 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <4C76EE04.1020905@mail-abuse.org> <20100827142523.GB22108@shinkuro.com> <4C77CF97.8040307@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 15:02:37 -0000 On 27.8.2010 16:49, Nicholas Weaver wrote: > > On Aug 27, 2010, at 7:45 AM, OndÅ™ej Surý wrote: > >> On 27.8.2010 16:42, Phillip Hallam-Baker wrote: >>> The reason that the reverse tree is not properly managed is that >>> doing so is not necessary for most Web applications. >>> >>> I would see the utility of this approach being for use with >>> applications such as SSH and other network management tools that >>> are used by the type of people who make sure their reverse DNS >>> works should they actually need it. >> >> May I remind this list, that SSH is out of the scope? And we >> already have a existing SSHFP RR. So when you think about reverse >> tree, please don't include SSH nor IPSec. > > Uh, actually SSH IMO, is perfectly in scope. > > The real scope is not new resource records but new APIs and > techniques: You may be able to get the SSHFP RR today, but we need > ways for the SSH application to validate that the key is indeed > valid, and we need protocol and policy to get reverse lookups to be > reliable in this case. Let me rephrase what I said... The SSH and IPSec was out of scope when we created this mailing list, called the BoF and planned the creation of WG. So I still think the SSH is out-of-the-scope. And I personally would like to keep it that way. Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84BA3A6A7F for ; Fri, 27 Aug 2010 08:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUfuRSEgdmUw for ; Fri, 27 Aug 2010 08:02:10 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id D31983A6A80 for ; Fri, 27 Aug 2010 08:02:10 -0700 (PDT) Received: by pvg7 with SMTP id 7so1322825pvg.31 for ; Fri, 27 Aug 2010 08:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P1ooIEdCUeJ56uyRW9XOqixYu9RRTNHUDK99ZcnDBrk=; b=Dqlntv04j68abRxHKefeF45Ty8gaOB3xa1e67Q/I6CEO1w2mflTe+8rMQv03ihZeKK ln1Nu82dvdeYIE2B/a0DU5AkXsi16dODPJyNsItNkQIA6LJR2G4dcqAKWjgScUzaiopX h6ERGKOps0J+57X1iLLaUgQgDVlh470UIHmcI= 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:content-transfer-encoding; b=V3huKtPKyDU2TU+mlNlD2fol106mt79LjboFGGl+FDLKVe1WXIcAJb3QGWS9SCp36c dAxzcW0tEsuoC3sl/JtD7yGRtHhf/j6jLEkYteahQtl7Qwyvleqik+9up8VDpxy9cVNM oDwM2/REx4qtU46P9/3qSNtqBi7TZH8fUOTx8= MIME-Version: 1.0 Received: by 10.142.133.18 with SMTP id g18mr1267598wfd.228.1282921362894; Fri, 27 Aug 2010 08:02:42 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Fri, 27 Aug 2010 08:02:38 -0700 (PDT) In-Reply-To: <4C77CF97.8040307@nic.cz> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <4C76EE04.1020905@mail-abuse.org> <20100827142523.GB22108@shinkuro.com> <4C77CF97.8040307@nic.cz> Date: Fri, 27 Aug 2010 11:02:38 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 15:02:12 -0000 At the moment we are still discussing scope. Paul's original list request was for 'applications'. Whether design of mechanisms to support email and SSH are in scope for the group, the group would be remarkably ill advised to ignore DKIM and SSHFP. In particular, should the group choose to re-use the CERT record it is obliged to consider the effect on other applications. and in particular the question of whether keys presented in certificates should be presented in the CERT or SSHFP record is going to have to be considered. On Fri, Aug 27, 2010 at 10:45 AM, Ond=F8ej Sur=FD wrot= e: > On 27.8.2010 16:42, Phillip Hallam-Baker wrote: >> >> The reason that the reverse tree is not properly managed is that doing >> so is not necessary for most Web applications. >> >> I would see the utility of this approach being for use with >> applications such as SSH and other network management tools that are >> used by the type of people who make sure their reverse DNS works >> should they actually need it. > > May I remind this list, that SSH is out of the scope? =A0And we already h= ave a > existing SSHFP RR. =A0So when you think about reverse tree, please don't > include SSH nor IPSec. > > Ondrej > -- > =A0Ond=F8ej Sur=FD > =A0vedouc=ED v=FDzkumu/Head of R&D department > =A0------------------------------------------- > =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC > =A0Americka 23, 120 00 Praha 2, Czech Republic > =A0mailto:ondrej.sury@nic.cz =A0 =A0http://nic.cz/ > =A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112 > =A0------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4FFF3A6AA8 for ; Fri, 27 Aug 2010 07:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCB8+WM1xwHQ for ; Fri, 27 Aug 2010 07:48:44 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 982363A6A27 for ; Fri, 27 Aug 2010 07:48:43 -0700 (PDT) Received: by pzk6 with SMTP id 6so1301096pzk.31 for ; Fri, 27 Aug 2010 07:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=XGiDEKWOpUtSlFWOpxn2fZ484tJHIuq6Hl15uLBOmcE=; b=t9h99wORl6O7k/wRWss70vTe96/2xoCWcX/zGsVk182jSBxEWrfBwzsuhUh6CgZmRG CjBp7W9CSwzUXtauSiIZWH9mvO05yoWQe6GwG7aY/qVWIKW0X8zU9/A4aoH9a6BJBQps COHfRPtkN+j4xmBB0kXePqGsv22c5e05RS+JY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=W8gfPr0fqTSU4X8ekmn3WK86qhHJf5eiISWIV+M7LVcqMsQ9vmb+upHr9ZHKnSpEzC JUJmudTs7m4BWGx47uq87r6RvZeq9GbPQkaurK9FeQPeeBFh5TgiHMptjjoCxSvIqErp RoE2syP/QoTndwpEZw69yVX//qA48ljaVS0eM= Received: by 10.143.13.8 with SMTP id q8mr1367594wfi.1.1282920555652; Fri, 27 Aug 2010 07:49:15 -0700 (PDT) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) by mx.google.com with ESMTPS id y16sm4522811wff.14.2010.08.27.07.49.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Aug 2010 07:49:14 -0700 (PDT) Sender: Nicholas Weaver Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Nicholas Weaver In-Reply-To: <4C77CF97.8040307@nic.cz> Date: Fri, 27 Aug 2010 07:49:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <4C76EE04.1020905@mail-abuse.org> <20100827142523.GB22108@shinkuro.com> <4C77CF97.8040307@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 14:48:45 -0000 On Aug 27, 2010, at 7:45 AM, Ond=C5=99ej Sur=C3=BD wrote: > On 27.8.2010 16:42, Phillip Hallam-Baker wrote: >> The reason that the reverse tree is not properly managed is that = doing >> so is not necessary for most Web applications. >>=20 >> I would see the utility of this approach being for use with >> applications such as SSH and other network management tools that are >> used by the type of people who make sure their reverse DNS works >> should they actually need it. >=20 > May I remind this list, that SSH is out of the scope? And we already = have a existing SSHFP RR. So when you think about reverse tree, please = don't include SSH nor IPSec. Uh, actually SSH IMO, is perfectly in scope. =20 The real scope is not new resource records but new APIs and techniques: = You may be able to get the SSHFP RR today, but we need ways for the SSH = application to validate that the key is indeed valid, and we need = protocol and policy to get reverse lookups to be reliable in this case. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C453A67F3 for ; Fri, 27 Aug 2010 07:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_40=-0.185, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftE5-mK5gsCS for ; Fri, 27 Aug 2010 07:45:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 3698E3A67E5 for ; Fri, 27 Aug 2010 07:45:12 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 729DC7343AA for ; Fri, 27 Aug 2010 16:45:43 +0200 (CEST) Message-ID: <4C77CF97.8040307@nic.cz> Date: Fri, 27 Aug 2010 16:45:43 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <4C76EE04.1020905@mail-abuse.org> <20100827142523.GB22108@shinkuro.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 14:45:13 -0000 On 27.8.2010 16:42, Phillip Hallam-Baker wrote: > The reason that the reverse tree is not properly managed is that doing > so is not necessary for most Web applications. > > I would see the utility of this approach being for use with > applications such as SSH and other network management tools that are > used by the type of people who make sure their reverse DNS works > should they actually need it. May I remind this list, that SSH is out of the scope? And we already have a existing SSHFP RR. So when you think about reverse tree, please don't include SSH nor IPSec. Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B8F3A681A for ; Fri, 27 Aug 2010 07:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfqzZSGEF8QU for ; Fri, 27 Aug 2010 07:41:35 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 4E17A3A6974 for ; Fri, 27 Aug 2010 07:41:35 -0700 (PDT) Received: by gwb20 with SMTP id 20so1393438gwb.31 for ; Fri, 27 Aug 2010 07:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=KWFmR4P+LkOYv0Po963FH8aK/cH4t1MPMKma7ebGfus=; b=ewOiqIhXWf6LLc+fKWFeY4zrN9xd84v4Lx3d/wd06UnVTFyxODM+fkIjhXr/mwVEPh Brxbjb5GBuOSbNVFR1yXGiX68kw1ku72mpciakzGgXPCbdaEdTonjxmVj4LxbBu6Num7 ymUTXkNR0wu/NyGyKg/RvB93LjMaNDXBOsNkY= 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=OKERxutYI3FfJYVQvMAe3bLQQXN+Q4MeB+WA/epdl0UNvLHzmxefsNwXs69h5HvlLm nG/IC/rY2xk86v1oiba3gK9scoYEjdoO0FudPapfQMZTT/9hiWBFcFAYwhlDpkV+Xrq1 rx9hGDbc1Zcfo4+aMvOyiWQps9VqNv4ZjORoM= MIME-Version: 1.0 Received: by 10.150.54.11 with SMTP id c11mr2047245yba.124.1282920127173; Fri, 27 Aug 2010 07:42:07 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Fri, 27 Aug 2010 07:42:06 -0700 (PDT) In-Reply-To: <20100827142523.GB22108@shinkuro.com> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <4C76EE04.1020905@mail-abuse.org> <20100827142523.GB22108@shinkuro.com> Date: Fri, 27 Aug 2010 10:42:06 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 14:41:36 -0000 The reason that the reverse tree is not properly managed is that doing so is not necessary for most Web applications. I would see the utility of this approach being for use with applications such as SSH and other network management tools that are used by the type of people who make sure their reverse DNS works should they actually need it. It is not going to be possible to use the ICANN root in private IP space of course (10.x.x.x, 192.168.x.x). But if you have 1000 servers it is one heck of a lot easier to distribute one private root of trust to an application like SSH than 1000 end entity keys. And in this context ease of use means more security. I would like to get away from the idea of 'using DNSSEC' as the basis for this group and instead using 'Secure DNS' of which DNSSEC is one realization. All that matters in order to have a trustworthy means of keying SSH is that the data in the CERT record is trustworthy and that the CERT record is presented to the client with a trustworthy means of authentication trusted by the client. It is far too late to use DNS Curve for inter-domain security in my view. But the use of a similar approach to support intra-domain security between the client and server is very much on the table as far as I am concerned (albeit not in this group). It is a model that has considerable sympathy and champions in Microsoft and other major vendors. On Fri, Aug 27, 2010 at 10:25 AM, Andrew Sullivan wrote: > On Thu, Aug 26, 2010 at 03:43:16PM -0700, Douglas Otis wrote: >> For cases where clients do not exchange domain names, reverse DNS could >> be utilized to authenticate clients. > > Except, of course, that you can't really rely on the reverse tree > being managed. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F241E3A67CC for ; Fri, 27 Aug 2010 07:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.539 X-Spam-Level: X-Spam-Status: No, score=-101.539 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdsI95glYPvc for ; Fri, 27 Aug 2010 07:24:56 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 027073A681B for ; Fri, 27 Aug 2010 07:24:56 -0700 (PDT) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F16971ECB41D for ; Fri, 27 Aug 2010 14:25:25 +0000 (UTC) Date: Fri, 27 Aug 2010 10:25:23 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20100827142523.GB22108@shinkuro.com> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <4C76EE04.1020905@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C76EE04.1020905@mail-abuse.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 14:24:57 -0000 On Thu, Aug 26, 2010 at 03:43:16PM -0700, Douglas Otis wrote: > For cases where clients do not exchange domain names, reverse DNS could > be utilized to authenticate clients. Except, of course, that you can't really rely on the reverse tree being managed. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0B23A6AA0 for ; Thu, 26 Aug 2010 20:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bzzjg2UYQnn8 for ; Thu, 26 Aug 2010 20:09:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 66E883A69CE for ; Thu, 26 Aug 2010 20:09:18 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:51291 helo=[192.168.163.88]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OopK9-000Aot-RN; Thu, 26 Aug 2010 23:09:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100826154810.GD19496@shinkuro.com> References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <1C4ED82F-D56D-4362-914F-C41A44327901@ICSI.Berkeley.EDU> <87hbii78bo.fsf@mocca.josefsson.org> <20100826154810.GD19496@shinkuro.com> Date: Thu, 26 Aug 2010 23:09:08 -0400 To: Andrew Sullivan From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Does this work need to be "better"? (was: Introducing draft-josefsson-keyassure-tls-00.txt) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 03:09:19 -0000 At 11:48 AM -0400 8/26/10, Andrew Sullivan wrote: >On Wed, Aug 25, 2010 at 07:18:30PM -0400, Stephen Kent wrote: >> one wants to provide via DNS-supplied keys or certs, and why the use of >> DNS to effect this function is better than extant mechanisms. If we can't >> clearly articulate this, then it is not clear that a Wg should be >> created. > >I don't see why it has to be "better" than. Surely "better for some >uses" or "useful alternative in some cases" are enough? Better for enough use cases to make it worthwhile to add to our plethora of standards :-). >I'm particularly uncomfortable with that "better" because it strikes >me as a way of sneaking in some premises that maybe not everyone will >grant. For instance, a DNSSEC-based approach is clearly not better >for showing cryptographically some relationship between a given name >and some particular legal entity. But one can simply set that issue >aside as not relevant for this use, and be agnostic on whether it >makes things "better". Relax. If the proposed work is better for some reasonable class of application contexts, then it makes sense. The fact that it is not likely to be a panacea ought not be part of the criteria. I like the latest charter statement form Warren, with the minor tweaks several folks have suggested. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7B33A6B17 for ; Thu, 26 Aug 2010 20:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWdZBIyC0Ly0 for ; Thu, 26 Aug 2010 20:08:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 84D143A69CE for ; Thu, 26 Aug 2010 20:08:26 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38964 helo=[192.168.163.88]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OopJI-00054m-4S; Thu, 26 Aug 2010 23:08:58 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <84580414-1F3F-4B01-A41E-A0AB130D53A4@bbn.com> <7B492A8E-4C44-4EB8-8B9E-7F7067309653@icsi.berkeley.edu> <1C711173-CE4B-48A5-90A1-9D628382EDB4@ICSI.Berkeley.EDU> Date: Thu, 26 Aug 2010 22:23:03 -0400 To: Phillip Hallam-Baker From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 03:08:28 -0000 At 8:54 AM -0400 8/26/10, Phillip Hallam-Baker wrote: >I don't think it is helpful to start bringing in the Security ADs >opinion unless they have stated an opinion. Their concurrence may be a >necessary condition, but certainly not a sufficient one. Agreed that it is necessary, but not sufficient. >You are correct that these are not self signed certificates in the >proposed mode of use. They are actually a CA issued certificate with >signature in the form of a countersignature on the self-signed >certificate prototype. OK. >The zone KSK may be established through a number of different means. > >These means are out of scope for this discussion. But one means that >you should probably consider in the context of making BGP security >practical is the case where the DNS zone KSK is signed using an X.509 >certificate expressed in a CERT record. I'm not sure how any DNSSEC capabilities relate to the RPKI that BGP secruity will rely upon. All 5 RIRs have committed to IOC for the RPKI on 1/1/11, based on a number of I-Ds that the SIDR WG is now aggressively pushing towards approval. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449223A6A5C for ; Thu, 26 Aug 2010 15:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.292 X-Spam-Level: X-Spam-Status: No, score=-106.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QOOvCV9yhUc for ; Thu, 26 Aug 2010 15:42:47 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 7C6FD3A6837 for ; Thu, 26 Aug 2010 15:42:47 -0700 (PDT) Received: from sjc-office-nat-210.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 43F3CA9451D for ; Thu, 26 Aug 2010 22:43:16 +0000 (UTC) Message-ID: <4C76EE04.1020905@mail-abuse.org> Date: Thu, 26 Aug 2010 15:43:16 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> In-Reply-To: <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 22:42:52 -0000 On 8/25/10 2:35 PM, Nicholas Weaver wrote: > On Aug 25, 2010, at 2:30 PM, Andrew Sullivan wrote: > > On Wed, Aug 25, 2010 at 05:14:59PM -0400, Richard L. Barnes wrote: > >> I would prefer the Objective be tightened a little to focus on > >> authenticating domain names, as opposed to, say, negotiating > >> crypto > > > > What do you mean "authenticating"? If what you want to do is > > ensure yourself that you're actually going to the right address, > > you can do that now. That's all DNSSEC does. > > Why not "discovering and authenticating cryptographic material which > is associated with a service located at a domain name"? There are two end points to consider, which is one of the glaring weaknesses found with TLS. Utilizing IPv6 address space for email will likely require a cryptographic means to verify both the client AND the server that are supporting a specific service, where there may be intervening address translations between connections. So rewritten just a bit, "Supporting the cryptographic authentication of either end of a network connection related to specific services utilizing resources published within DNS." For SMTP, this could utilize an SMTP Auth extension employing a public key referenced from the EHLO host name, or a domain declared within the authentication exchange. For cases where clients do not exchange domain names, reverse DNS could be utilized to authenticate clients. -Doug Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E8A3A685A for ; Thu, 26 Aug 2010 15:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_20=-0.74, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKZgT6236MwE for ; Thu, 26 Aug 2010 15:35:14 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id A1BC93A6837 for ; Thu, 26 Aug 2010 15:35:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=O/xelDG8U8Cw/wrviInStRb+wz9xfs4ZIJ6XtFaYFJn0AzQzrMqvQdSwG3t71kvy; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.45] (helo=elwamui-polski.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Ool2H-0006M9-Ay; Thu, 26 Aug 2010 18:35:05 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Thu, 26 Aug 2010 18:34:56 -0400 Message-ID: <18979325.1282862097067.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> Date: Thu, 26 Aug 2010 17:34:56 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: bmanning@vacation.karoshi.com, Paul Hoffman Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606880f15ce2e921e85076642385c6daaf75f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.45 Cc: Phillip Hallam-Baker , keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 22:35:16 -0000 Paul and all, That's how I interprit the discussion thus far, yes... -----Original Message----- >From: bmanning@vacation.karoshi.com >Sent: Aug 26, 2010 4:22 PM >To: Paul Hoffman >Cc: keyassure@ietf.org, Phillip Hallam-Baker >Subject: Re: [keyassure] Poking the charter bear.... > > > so, there seems to be tacit agreement that the entire DNS tree > is fair game under the text Warren posted... mod the existance > of IDs et.al. > >--bill > > >On Thu, Aug 26, 2010 at 01:21:28PM -0700, Paul Hoffman wrote: >> At 3:55 PM -0400 8/26/10, Phillip Hallam-Baker wrote: >> >Looks like a cop out to me. >> >> One person's prudent use of resources is another person's cop-out. >> >> >Putting certs in the reverse DNS may turn out to be useless. But we >> >have to understand why it is useless if we are going to be able to >> >claim that we understand the proposals for the forward DNS. >> >> We will never know until there are one or more concrete proposals, hopefully written as Internet Drafts and not just a changing thread on a mailing list. >> >> >> --Paul Hoffman, Director >> --VPN Consortium >> _______________________________________________ Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905423A6B09 for ; Thu, 26 Aug 2010 14:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.039 X-Spam-Level: X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEfswDpDLZXR for ; Thu, 26 Aug 2010 14:22:14 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 9D1AF3A6AFC for ; Thu, 26 Aug 2010 14:22:14 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o7QLMRA1007431; Thu, 26 Aug 2010 21:22:33 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o7QLMR1X007430; Thu, 26 Aug 2010 21:22:27 GMT Date: Thu, 26 Aug 2010 21:22:18 +0000 From: bmanning@vacation.karoshi.com To: Paul Hoffman Message-ID: <20100826212218.GA7025@vacation.karoshi.com.> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <20100826173548.GB6663@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: keyassure@ietf.org, Phillip Hallam-Baker Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 21:22:15 -0000 so, there seems to be tacit agreement that the entire DNS tree is fair game under the text Warren posted... mod the existance of IDs et.al. --bill On Thu, Aug 26, 2010 at 01:21:28PM -0700, Paul Hoffman wrote: > At 3:55 PM -0400 8/26/10, Phillip Hallam-Baker wrote: > >Looks like a cop out to me. > > One person's prudent use of resources is another person's cop-out. > > >Putting certs in the reverse DNS may turn out to be useless. But we > >have to understand why it is useless if we are going to be able to > >claim that we understand the proposals for the forward DNS. > > We will never know until there are one or more concrete proposals, hopefully written as Internet Drafts and not just a changing thread on a mailing list. > > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417413A6B07 for ; Thu, 26 Aug 2010 14:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckc-lBg+WsHm for ; Thu, 26 Aug 2010 14:15:40 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 8D2033A6B0D for ; Thu, 26 Aug 2010 14:15:40 -0700 (PDT) Received: by yxk8 with SMTP id 8so1008265yxk.31 for ; Thu, 26 Aug 2010 14:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=M3sVFHsVqNc86ERQlsI8KUNc1g0ww9gNesGNCEIT1GY=; b=FlURjrdlrKN1qRs6fXLgmzRv86G1Wn0gI8Hm4thdw0fgoCGsp0nx33M6rtkMigB4MD vvPzfKJfTQbp4Xs3y9oF2eVDPk5MyUqYuYpsH+b1qsTYsUhcxdClIvE1NgL1hXdrtm2u SrqnVh9uQ3eNAzy5qnTw3jiqUfrwEXovX5JU4= 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=CXmvrOHDC/WvID8FMP//PvQOTLFKGEDvJn/N8tpAeqtxxbY43kwR9ZO/iBDDIcQzW/ 1OztPFz2qhYJ4WT0iOHsb6kPOkpdFJstcnpN0KTYinDtsJ0Y9S+PHKIvDKEWzfN4uFI1 ylKD5l3WW1l9Kmf9hCWGCm/PR2xIHwRMCZmxA= MIME-Version: 1.0 Received: by 10.90.25.2 with SMTP id 2mr1055296agy.84.1282857372388; Thu, 26 Aug 2010 14:16:12 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Thu, 26 Aug 2010 14:16:12 -0700 (PDT) In-Reply-To: References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <20100826173548.GB6663@vacation.karoshi.com.> Date: Thu, 26 Aug 2010 17:16:12 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 21:15:42 -0000 I very much doubt that we can come to consensus for a use for it. Provisioning of the reverse DNS is pretty patchy for a start. But I can definitely see a use for it with SSH. If someone is debugging a network they are going to see an IP address, not a domain name. But time spent understanding the problem is not wasted. If I want to understand a protocol proposal I apply it to something that the designer probably didn't consider. It is a really great way to understand the corner cases you have to solve. I have seen years wasted in IETF WG by people who insisted that everything apart from their little piece of the problem be out of scope.There is a particularly bad history of that in the DNS area. It took four years to get the WG to accept that the EU privacy directive was significant and less than six months to fix the problem. What I think we are looking at in the short term is not actually a WG. It is a fairly short proposal to describe a new prefix based approach to discovery of CERT records and a couple of new fields for data types. I generally try to understand the problem before I write an Internet Draft. I find that approach is generally better. On Thu, Aug 26, 2010 at 4:21 PM, Paul Hoffman wrote: > At 3:55 PM -0400 8/26/10, Phillip Hallam-Baker wrote: >>Looks like a cop out to me. > > One person's prudent use of resources is another person's cop-out. > >>Putting certs in the reverse DNS may turn out to be useless. But we >>have to understand why it is useless if we are going to be able to >>claim that we understand the proposals for the forward DNS. > > We will never know until there are one or more concrete proposals, hopefully written as Internet Drafts and not just a changing thread on a mailing list. > > > --Paul Hoffman, Director > --VPN Consortium > -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FEE13A6937 for ; Thu, 26 Aug 2010 13:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6Jd16BV6n4d for ; Thu, 26 Aug 2010 13:59:42 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id C4B6A3A683E for ; Thu, 26 Aug 2010 13:59:42 -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 ECB84C17D; Thu, 26 Aug 2010 17:00:13 -0400 (EDT) Date: Thu, 26 Aug 2010 17:00:13 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <20100826173548.GB6663@vacation.karoshi.com.> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org, Phillip Hallam-Baker Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 20:59:45 -0000 On Thu, 26 Aug 2010, Paul Hoffman wrote: > At 3:55 PM -0400 8/26/10, Phillip Hallam-Baker wrote: >> Looks like a cop out to me. > > One person's prudent use of resources is another person's cop-out. > >> Putting certs in the reverse DNS may turn out to be useless. But we >> have to understand why it is useless if we are going to be able to >> claim that we understand the proposals for the forward DNS. > > We will never know until there are one or more concrete proposals, hopefully written as Internet Drafts and not just a changing thread on a mailing list. The FreeS/WAN project tried to use the rever tree for TXT records with pubkeys in it. It failed miserably because endusers tend to not be able to do anything about their reverse. There might still be a legitimate use for servers and sysadmins though. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC0C3A6ACA for ; Thu, 26 Aug 2010 13:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.761 X-Spam-Level: X-Spam-Status: No, score=-99.761 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYpSm3p5Neq5 for ; Thu, 26 Aug 2010 13:20:59 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id B1B7D3A6AB2 for ; Thu, 26 Aug 2010 13:20:59 -0700 (PDT) Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7QKLTAw050075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Aug 2010 13:21:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <20100826173548.GB6663@vacation.karoshi.com.> Date: Thu, 26 Aug 2010 13:21:28 -0700 To: Phillip Hallam-Baker From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 20:21:00 -0000 At 3:55 PM -0400 8/26/10, Phillip Hallam-Baker wrote: >Looks like a cop out to me. One person's prudent use of resources is another person's cop-out. >Putting certs in the reverse DNS may turn out to be useless. But we >have to understand why it is useless if we are going to be able to >claim that we understand the proposals for the forward DNS. We will never know until there are one or more concrete proposals, hopefully written as Internet Drafts and not just a changing thread on a mailing list. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B643A6AA7 for ; Thu, 26 Aug 2010 13:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3it9vxVvnXHJ for ; Thu, 26 Aug 2010 13:19:34 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 054B23A68F3 for ; Thu, 26 Aug 2010 13:19:33 -0700 (PDT) Received: by pzk6 with SMTP id 6so931288pzk.31 for ; Thu, 26 Aug 2010 13:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=wxFv9Rg6iKSAGAZcuetzv+q4P4NkkwVF2PiuF2Y/+sM=; b=ooV96hnu3YpIeoPkk8kJDo4gXPeTBiHXyQGco7PDr14MyCDLgMeVVkIIcIIt/cp2lC UOrLNC8N7kN9cDwkiUXboVC7XF9rSP54G5feDnwTUs1CmFxc7rDzSK/YywjgGrguqlZ3 YM4o/tPszQYhmyGJhV1+gGgPcbfMEBaKzitcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=ZdKoWOilJMuuw/MxnfCbTRZ7Z0e/nQj+WXkVDm16QrUuolNKdcGKI1ZHihS6aKEpN+ Dq9CPeP3Ek+AnvD4V6i0ULFeVbyfz/DZSnmzi36v9mWU4eKxFQMmHDqTwIpQUFxiHncZ T//e5SgpjjWOyrfAZV+R6dqxfVZAEZf2aPgUA= Received: by 10.114.111.13 with SMTP id j13mr11769300wac.123.1282854006020; Thu, 26 Aug 2010 13:20:06 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id c10sm5079557wam.1.2010.08.26.13.20.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Aug 2010 13:20:04 -0700 (PDT) Sender: Nicholas Weaver References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <20100826173548.GB6663@vacation.karoshi.com.> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <74BF5D80-BCA4-4A35-A4B2-80B14961E365@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Thu, 26 Aug 2010 13:20:01 -0700 To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 20:19:35 -0000 On Aug 26, 2010, at 12:55 PM, Phillip Hallam-Baker wrote: > Looks like a cop out to me. >=20 > Putting certs in the reverse DNS may turn out to be useless. But we > have to understand why it is useless if we are going to be able to > claim that we understand the proposals for the forward DNS. >=20 > None of these schemes are going to make any sense except in the > context of an application. >=20 >=20 > Binding a cert to an IP address is does not seem to be very useful in > an application layer protocol. But it could be very useful in a > routing layer protocol. For example, BGP security. I can also see > cases where it might be used to exchange messages reporting abusive > behavior. >=20 > In the case of establishing a WiFi connection at an access point such > as a coffee shop, this would seem to me to be a rather useful > approach. SSH can connect by both IP and hostname, and the known-hosts file will = do things by IP. Thus at least for SSH it makes sense to store records = associated with reverse names as well. And once again, there is a single possible path-of-trust involved, but = this one rather than passing through the chain of . -> domain registrar -> domain owner -> subdomain owner it passes through the chain of . -> network registrar -> ISP -> ?ISP? -> network owner (and in both cases, a service identifier could be prepended onto the = name). The coffie shop perhaps less so: the access point is probably NAT'ed, so = everything is in 10. or 192.168. space. Getting an external IPv4 = address for the WAP seems difficult/uselesss. But there may be a role = in IPv6: you get the key for the gateway's IPv6 address and that might = make sense. Thus to me it makes sense to examine usages which bind key material to = reverse names as well as forward names, since the reverse name chain of = trust is like the forward name chain of trust: there exists not only a = single valid path, but it is along (a different) already established = relationships. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A473A68F3 for ; Thu, 26 Aug 2010 12:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GssB56SSpJeB for ; Thu, 26 Aug 2010 12:55:17 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 856263A68BF for ; Thu, 26 Aug 2010 12:55:17 -0700 (PDT) Received: by iwn3 with SMTP id 3so2014394iwn.31 for ; Thu, 26 Aug 2010 12:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2Gv6k3A2nYC3mOOQMPtlV+sEKuoLymNvUCZ3khBFxJM=; b=IVLBQXwY4v03ZPy4zNPTMNdGmLnzypkCkSdMCIgM64FAItmdFCQAmcvUmObHrBWtXt th991LR1z87gwF37qOtuoduDLB83nJp9UHdF5dpiVVHwR/EQez51fYOMj8gi0tqg6RC2 1cX39igCOc38Ilh+IO+QZ7YQ3ZfobVwaHhhsA= 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:content-transfer-encoding; b=c9xwARmzOJ0H+7fyTimhB4xqsFNeccSEGFcGaj88gRb0NGMEgmuSLP76b3SLSGxLYV 6TuuPLxneUD9Vla7Y1n3UBaqpwKD0C6st7vzPvnVEnz8KzJpSN6rlHh5Kd23cTF8CHfW G3TNAbJ5CfFH2PAW1vNz56XDcF59DElsUW/KY= MIME-Version: 1.0 Received: by 10.231.169.149 with SMTP id z21mr12583943iby.11.1282852549647; Thu, 26 Aug 2010 12:55:49 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Thu, 26 Aug 2010 12:55:49 -0700 (PDT) In-Reply-To: References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <20100826173548.GB6663@vacation.karoshi.com.> Date: Thu, 26 Aug 2010 15:55:49 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 19:55:18 -0000 Looks like a cop out to me. Putting certs in the reverse DNS may turn out to be useless. But we have to understand why it is useless if we are going to be able to claim that we understand the proposals for the forward DNS. None of these schemes are going to make any sense except in the context of an application. Binding a cert to an IP address is does not seem to be very useful in an application layer protocol. But it could be very useful in a routing layer protocol. For example, BGP security. I can also see cases where it might be used to exchange messages reporting abusive behavior. In the case of establishing a WiFi connection at an access point such as a coffee shop, this would seem to me to be a rather useful approach. On Thu, Aug 26, 2010 at 2:01 PM, Paul Hoffman wrote= : > At 5:35 PM +0000 8/26/10, bmanning@vacation.karoshi.com wrote: >> wander off for a few days and look what happens! :) >> >> i have a question for the assembled masses... >> >> when the text below referes to "domain names" does this include >> _all_ domain names or just those in the forward tree? =A0i.e. >> >> any problems using >> >> =A0 =A0 =A0 53.30.168.192.in-addr.arpa. >> >> as a domain name? > > Now thar's some good poking! > > I definitely have a problem with that name for what is in the charter in = that I would hope that there could not be a server running TLS at the addre= sses in the A or AAAA records returned from a query sent for 53.30.168.192.= in-addr.arpa. > > And, just in case you were messing with us by choosing a private address = space, I would say exactly the same thing for 81.41.182.207.in-addr.arpa. > > The CNAME and SRV indirection threads here have not yielded widespread ag= reement; I think PTR indirection should be added to the list of things we m= ight consider but might gingerly back away from. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674363A698F for ; Thu, 26 Aug 2010 11:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.128 X-Spam-Level: X-Spam-Status: No, score=-100.128 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKlL7SaMi4lK for ; Thu, 26 Aug 2010 11:00:55 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 852F53A68DA for ; Thu, 26 Aug 2010 11:00:55 -0700 (PDT) Received: from [10.20.30.158] (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 o7QI1Qr0042873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Aug 2010 11:01:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100826173548.GB6663@vacation.karoshi.com.> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <20100826173548.GB6663@vacation.karoshi.com.> Date: Thu, 26 Aug 2010 11:01:23 -0700 To: bmanning@vacation.karoshi.com, Warren Kumari From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 18:00:56 -0000 At 5:35 PM +0000 8/26/10, bmanning@vacation.karoshi.com wrote: > wander off for a few days and look what happens! :) > > i have a question for the assembled masses... > > when the text below referes to "domain names" does this include > _all_ domain names or just those in the forward tree? i.e. > > any problems using > > 53.30.168.192.in-addr.arpa. > > as a domain name? Now thar's some good poking! I definitely have a problem with that name for what is in the charter in that I would hope that there could not be a server running TLS at the addresses in the A or AAAA records returned from a query sent for 53.30.168.192.in-addr.arpa. And, just in case you were messing with us by choosing a private address space, I would say exactly the same thing for 81.41.182.207.in-addr.arpa. The CNAME and SRV indirection threads here have not yielded widespread agreement; I think PTR indirection should be added to the list of things we might consider but might gingerly back away from. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097E53A68E9 for ; Thu, 26 Aug 2010 10:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyUPZYaxC0+p for ; Thu, 26 Aug 2010 10:35:38 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 17BAE3A6864 for ; Thu, 26 Aug 2010 10:35:28 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o7QHZsA1006717; Thu, 26 Aug 2010 17:35:55 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o7QHZm2H006716; Thu, 26 Aug 2010 17:35:48 GMT Date: Thu, 26 Aug 2010 17:35:48 +0000 From: bmanning@vacation.karoshi.com To: Warren Kumari Message-ID: <20100826173548.GB6663@vacation.karoshi.com.> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> User-Agent: Mutt/1.4.1i Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 17:35:45 -0000 wander off for a few days and look what happens! :) i have a question for the assembled masses... when the text below referes to "domain names" does this include _all_ domain names or just those in the forward tree? i.e. any problems using 53.30.168.192.in-addr.arpa. as a domain name? --bill On Wed, Aug 25, 2010 at 04:59:01PM -0400, Warren Kumari wrote: > So, a while back we had some discussions about a possible charter for > a possible working group. This discussion sort of veered off course, > so this is a new thread, unencumbered by previous grumpiness... > > I have tried to distill essence from various folks comments and > proposed charters and come up with something that we can all (yeah, > right!) agree on... How do folk feel about the below? > > ----------------------------------- > Objective: > > Specify mechanisms and techniques that allow Internet applications to > establish cryptographically secured communications through use of > information distributed through the DNS. > > Problem Statement: > > Entities on the Internet are usually identified by domain names and > forming a cryptographically secured connection to the entity requires > the entity to authenticate its name. For instance, in HTTPS, a server > responding to a query for is expected to > authenticate as "www.example.com". Security protocols such as TLS and > IPsec accomplish this authentication by allowing an endpoint to prove > ownership of a private key whose corresponding public key is somehow > bound to the name being authenticated. As a pre-requisite for > authentication, then, these protocols require a mechanism for bindings > to be asserted between public keys and domain names. > > DNSSEC provides a mechanism for a domain operator to sign DNS > information directly, using keys that are bound to the domain by the > parent domain; relying parties can continue this chain up to any trust > anchor that they accept. In this way, bindings of keys to domains are > asserted not by external entities, but by the entities that operate > the DNS. In addition, this technique inherently limits the scope of > any given entity to the names in zones he controls. > > This working group will develop mechanisms for domain operators to > present bindings between names within their control and public keys, > in such a way that these bindings can be integrity-protected (and thus > shown to be authentically from the domain operator) using DNSSEC and > used as a basis for authentication in protocols that use domain names > as identifiers. The group may also specify updates or clarifications > to protocols to describe how protocol entities discover and validate > these bindings in the execution of specific applications. > > --------------------------- > > I have attempted to pull bits from various people suggestions, and > this is a compromise -- I don't expect anyone to love it, but I hope > that it at least acceptable to most. I'm hoping that we can keep this > discussion on topic.... > > Whether or not this ends up being considered as a charter for a > possible WG is not important, what is is that we have some rough idea > of what we think we are hoping to accomplish... > > > W > > Below are the provided texts that I mainly pulled from (and then > massaged to try and remove the point ends). > > -------------- > Ondrej Sury (apologies for pure ASCII munging) and myself had written > the original draft proposed charter as: > ---- > Problem Statement: > > The DNS Security Extensions are a collection of resource records and > protocol modifications that provide source authentication for the DNS. > > The DNSSEC signed root infrastructure provides a single, well > published trust-anchor and a method to build a chain of trust from an > individual resource record (RR) to that TA. By leveraging this > infrastructure we can securely bind information (such as a public key, > certificate identifier, etc) to a DNS name. > > Increasingly people would like to be able to take advantage of the > confidentiality and identity validation provided by protocols such as > TLS. There are numerous barriers to this, including cost, ease of use, > complexity, certificate management, etc. By allowing users to securely > publish public key information we can allow users to easily and > securely make use of self-signed certificates. > > Currently, one of the issues limiting the use of self-signed > certificates is the difficulty in key-distribution - it is infeasible > to distribute a key binding at the web scale. By providing a means to > publish (and securely validate) this information in the DNS, we allow > for users to attest to the validity of keying information and > establish trust in the published public key. > > The DNSSEC root trust anchor can also be used for additional > validation during the current path validations. By validating that > the certificate presented is the certificate identified by the DNS, > we can provide additional confidence that the client is connecting to > the intended server - this helps alleviate concerns that a valid > certificate has been obtained by an attacker (for example from a CA > not used by the victim). > ----- > > Phillip Hallam-Baker has proposed: > ---- > Objective: > > Specify mechanisms that allow Internet applications to establish > cryptographically enhanced communications through use of information > distributed through the DNS. > > Problem Statement: > > Today the Internet is insecure by default and security is the > exception. If the security of the Internet is to be improved, security > must become the default. In particular modern computers have the > ability to employ cryptographic security enhancements with minimal or > negligible impact on performance, yet only a tiny proportion of > Internet traffic is encrypted or authenticated. > > One of the key weaknesses of the current Internet Public Key > Infrastructure (PKI) is that the most widely used Internet PKI is > based on the X.500 Directory scheme intended to support an entirely > different networking infrastructure. > > The naming infrastructure of the Internet is the DNS, not X.500. While > the PKIX specifications provide a means of mapping X.509v3 attributes > to DNS names there is currently no widely accepted, generalized means > of achieving the mapping from DNS names to X.509 certificates in > particular or to cryptographic keying material in general. DKIM and > SSH have demonstrated the utility of this approach in specific > domains, these specifications > > Recent progress in deployment of DNSSEC has renewed focus on the use > of the DNS naming system to support cryptographic operations. In > particular: > > * Discovery of keying material by DNS name > * Discovery of security criteria by DNS names > * Verification of keying material through DNSSEC trust chains > > Scope: > > * Use of existing security protocols with DNS established keys > * Use of DNS to verify existing certificate / keysigning / security > assertion material formats > * Means of verifying key/certificate chains using DNSSEC exclusively > * Means of verifying key/certificate chains using DNSSEC in > combination with other existing means > > Out-Of-Scope: > > * Reason for choice of specific trust paths > * New formats for keying material (other than raw keys) > * New trust architectures (unless they can be expressed in existing > formats > > > ---- > And Richard L. Barnes has provided: > Objective: > > Specify mechanisms for Internet applications to use information > distributed through the DNS to establish cryptographically assured > bindings between domain names and public keys. > > Problem Statement: > > Many Internet applications require protocol entities to authenticate > that they represent a certain domain name. For instance, in HTTPS, a > server responding to a query for is expected > to authenticate as "www.example.com". Security protocols such as TLS > and IPsec accomplish this authentication by allowing an endpoint to > prove ownership of a private key whose corresponding public key is > somehow bound to the name being authenticated. As a pre-requisite for > authentication, then, these protocols require a mechanism for bindings > to be asserted between public keys and domain names. > > In the past, these bindings have been asserted by parties external to > the DNS, using X.509 certificates. A certification authority (CA) can > create certificates that contain a domain name (e.g., as a Common Name > or dNSName Subject Alternative Name) and a public key. When a server > presents this certificate and proves ownership of the private key, a > relying party that trusts the CA to authenticate domain ownership can > be assured that the server legitimately represents the domain. > > One problem with this model is that the CAs that are typically used > have no relationship to the DNS infrastructure about which they are > making assertions. Modern browsers and operating systems typically > include more than a hundred CAs as trust anchors, any of which can > create a certificate for any domain name. > > DNSSEC provides a mechanism for a domain operator to sign DNS > information directly, using keys that are bound to the domain by the > parent domain; relying parties can continue this chain up to any trust > anchor that they accept. In this way, bindings of keys to domains are > asserted not by external entities, but by the entities that operate > the DNS. In addition to providing a more authoritative way of binding > DNS names to keys, this technique inherently limits the scope of any > given entity to the names in zones he controls. > > This working group will develop mechanisms for domain operators to > present bindings between names within their control and public keys, > in such a way that these bindings can be integrity-protected (and thus > shown to be authentically from the domain operator) using DNSSEC and > used as a basis for authentication in protocols that use domain names > as identifiers. The group may also specify updates or clarifications > to protocols to describe how protocol entities discover and validate > these bindings in the execution of a specific application. > > Note that this working group is specifically focused on bindings > between domain names and public keys, rather than bindings between > names and other sorts of information. For example, an X.509 > certificate can associate many types of information with its subject, > including things like IP address holdings and images of logos, as well > as bindings to higher-layer identities (e.g., corporate names). > Mechanisms developed by this group will not be focused on these > additional data, only on public keys. This basic binding might be > used, however, to associate a domain name with rich data by including > the same public key in the certificate that is bound to the domain. > > > > > > > -- > If the bad guys have copies of your MD5 passwords, then you have way > bigger problems than the bad guys having copies of your MD5 passwords. > -- Richard A Steenbergen > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76EC43A69BF for ; Thu, 26 Aug 2010 08:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.476 X-Spam-Level: X-Spam-Status: No, score=-101.476 tagged_above=-999 required=5 tests=[AWL=1.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrOP4ATwjcmn for ; Thu, 26 Aug 2010 08:47:39 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7DB193A6843 for ; Thu, 26 Aug 2010 08:47:39 -0700 (PDT) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CA9661ECB41D for ; Thu, 26 Aug 2010 15:48:11 +0000 (UTC) Date: Thu, 26 Aug 2010 11:48:10 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20100826154810.GD19496@shinkuro.com> References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <1C4ED82F-D56D-4362-914F-C41A44327901@ICSI.Berkeley.EDU> <87hbii78bo.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [keyassure] Does this work need to be "better"? (was: Introducing draft-josefsson-keyassure-tls-00.txt) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 15:47:40 -0000 On Wed, Aug 25, 2010 at 07:18:30PM -0400, Stephen Kent wrote: > one wants to provide via DNS-supplied keys or certs, and why the use of > DNS to effect this function is better than extant mechanisms. If we can't > clearly articulate this, then it is not clear that a Wg should be > created. I don't see why it has to be "better" than. Surely "better for some uses" or "useful alternative in some cases" are enough? I'm particularly uncomfortable with that "better" because it strikes me as a way of sneaking in some premises that maybe not everyone will grant. For instance, a DNSSEC-based approach is clearly not better for showing cryptographically some relationship between a given name and some particular legal entity. But one can simply set that issue aside as not relevant for this use, and be agnostic on whether it makes things "better". A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF753A6AC4 for ; Thu, 26 Aug 2010 05:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmXqo7BuzJUq for ; Thu, 26 Aug 2010 05:53:41 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id EE90F3A67E2 for ; Thu, 26 Aug 2010 05:53:40 -0700 (PDT) Received: by iwn3 with SMTP id 3so1750277iwn.31 for ; Thu, 26 Aug 2010 05:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BAKuD6Q2VecIcuEfjw6VjmdO1s8Rl4IRGQ/JauYtHow=; b=LaOeJFGEwu1OCaiqlOoGhWu0jMTa77Pn7lF4cHDiFib/Bmenka680wAEib9dVKaMHr OPOdhPFLqjXEuk2k+ZE9EDi6CN24KHEjptG2+fFRTb8XtK4+nX/BJD3timrpYCZ2tkio WvL8yVEBdOKMZ4F97eEP9Jn23aC+NW4Gov+XE= 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:content-transfer-encoding; b=AEwHeSqm2PJM8v2W5oBmINL2oT7CNPvaSTbME1zBGxqg4d310k/CbhtpR8avXEAApt 4MQlx4ka6Z11rac87ajwE/CS634Oo47mBK5CdUbAQhGXB0IX6eqAFJIeqSVY9yux7BhM 70Mj6U4VAnsS7eTUEX1uGuYrU+KT8kfRiOYXY= MIME-Version: 1.0 Received: by 10.231.39.196 with SMTP id h4mr11724732ibe.64.1282827251671; Thu, 26 Aug 2010 05:54:11 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Thu, 26 Aug 2010 05:54:11 -0700 (PDT) In-Reply-To: References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <84580414-1F3F-4B01-A41E-A0AB130D53A4@bbn.com> <7B492A8E-4C44-4EB8-8B9E-7F7067309653@icsi.berkeley.edu> <1C711173-CE4B-48A5-90A1-9D628382EDB4@ICSI.Berkeley.EDU> Date: Thu, 26 Aug 2010 08:54:11 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 12:53:42 -0000 I don't think it is helpful to start bringing in the Security ADs opinion unless they have stated an opinion. Their concurrence may be a necessary condition, but certainly not a sufficient one. You are correct that these are not self signed certificates in the proposed mode of use. They are actually a CA issued certificate with signature in the form of a countersignature on the self-signed certificate prototype. The zone KSK may be established through a number of different means. These means are out of scope for this discussion. But one means that you should probably consider in the context of making BGP security practical is the case where the DNS zone KSK is signed using an X.509 certificate expressed in a CERT record. On Wed, Aug 25, 2010 at 7:45 PM, Stephen Kent wrote: > At 4:30 PM -0700 8/25/10, Nicholas Weaver wrote: >> >> On Aug 25, 2010, at 4:11 PM, Stephen Kent wrote: >> >>> =A0At 9:59 AM -0700 8/25/10, Nicholas Weaver wrote: >>>> >>>> =A0On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote: >>>> =A0... >>>> >>>> =A0And is there really a difference? =A0A "CERT" is simply the key-for= mat >>>> desired by the application: SSL's CERTs are x509, but the "CERT" for S= SH is >>>> just the bare host key: this seems like a distinction without a differ= ence >>>> to me. >>> >>> =A0A public key cert is a assertion of a binding between a public key a= nd >>> =A0a set of attributes, signed by an entity attesting to the accuracy o= f >>> the assertion. This characterization applies to X.509 certs and PGP cer= ts. A >>> bare key is not a cert. =A0Let's not confuse terminology. >> >> For the purposes of storing records in DNS, is there a relevant >> distinction? >> I'd argue "absolutely not", especially since there is such a thing as >> "Self signed cert": a self signed certificate is really no different fro= m a >> bare key except for some garbage around it for formatting. > > I'd suggest that the SEC ADs will frown upon this cavalier use of > terminology, > which is inconsistent with RFC 4949 :-). > > A self-signed cert allows the signer to bind attributes to a public key, = in > a fashion that provides a consistency check, even though it does not prov= ide > a secure basis for authentication the identity of the Issuer/Subject. > > Steve > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A22CC3A68C3 for ; Wed, 25 Aug 2010 18:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H29ONXBAzZxv for ; Wed, 25 Aug 2010 18:54:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6FB2E3A6847 for ; Wed, 25 Aug 2010 18:54:49 -0700 (PDT) Received: from [128.89.253.200] (port=50807 helo=[192.168.1.43]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoRgX-000C3C-MD; Wed, 25 Aug 2010 21:55:22 -0400 Message-Id: From: "Richard L. Barnes" To: Warren Kumari In-Reply-To: <6D9D551A-EC0D-464A-A165-249ED9D7A834@kumari.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Aug 2010 21:55:20 -0400 References: <20100825233402.GA10325@odin.mars.sol> <6D9D551A-EC0D-464A-A165-249ED9D7A834@kumari.net> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Sample code X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 01:54:50 -0000 Yeah, there's more than a couple of things missing from this example (bounds checking, for example!). With respect to Scott's specific concern, I was thinking that this SSL context would only be used for connection in question, in which case it's just an issue of semantics: Whether having the cert in the DNS means that the host at that name will present exactly that cert or a cert subordinate to it. On Aug 25, 2010, at 9:01 PM, Warren Kumari wrote: > > On Aug 25, 2010, at 7:34 PM, Scott Schmit wrote: > >> On Mon, Aug 23, 2010 at 04:04:43PM -0400, Richard L. Barnes wrote: >>> // If we got a DNSSC-signed CERT record, add it to the SSL CA list >>> if (result->secure && result->havedata) { >>> // Read the X509 bytes into an OpenSSL X509 object >>> // Skip 5 bytes of type/tag/algorithm in the rrdata >>> unsigned char *cert_data = (unsigned char*) result->data[0] + 5; >>> int cert_len = result->len[0] - 5; >>> X509* cert = d2i_X509(NULL, cert_data, cert_len); >>> >>> // Mark the cert as a trusted CA cert >>> SSL_add_client_CA(ctx, cert); >> >> For what it's worth, depending on the context of this code, this >> could >> be a very bad thing to do. For example, if this is a CA certificate >> and >> another site presents a certificate signed by this one (but without >> DNSSEC, etc), it will be accepted as valid. > > Yes -- I don't think that this was intended to actually be used, but > rather just an example of how easily stuff like this around> can be done... > >> >> In other words, I don't think you can validate the certificates >> from DNS >> without taking into account the domain they are bound to, or you lose >> the benefit of this exercise. >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE923A68C3 for ; Wed, 25 Aug 2010 18:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxD0ukR5YC+N for ; Wed, 25 Aug 2010 18:20:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5EC273A68EA for ; Wed, 25 Aug 2010 18:20:23 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:44541 helo=[169.223.10.196]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoR9C-000De1-K7; Wed, 25 Aug 2010 21:20:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1C711173-CE4B-48A5-90A1-9D628382EDB4@ICSI.Berkeley.EDU> References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <84580414-1F3F-4B01-A41E-A0AB130D53A4@bbn.com> <7B492A8E-4C44-4EB8-8B9E-7F7067309653@icsi.berkeley.edu> <1C711173-CE4B-48A5-90A1-9D628382EDB4@ICSI.Berkeley.EDU> Date: Wed, 25 Aug 2010 19:45:23 -0400 To: Nicholas Weaver From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org, Nicholas Weaver Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 01:20:24 -0000 At 4:30 PM -0700 8/25/10, Nicholas Weaver wrote: >On Aug 25, 2010, at 4:11 PM, Stephen Kent wrote: > >> At 9:59 AM -0700 8/25/10, Nicholas Weaver wrote: >>> On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote: >>> ... >>> >>> And is there really a difference? A "CERT" is simply the >>>key-format desired by the application: SSL's CERTs are x509, but >>>the "CERT" for SSH is just the bare host key: this seems like a >>>distinction without a difference to me. >> >> A public key cert is a assertion of a binding between a public key and >> a set of attributes, signed by an entity attesting to the accuracy >>of the assertion. This characterization applies to X.509 certs and >>PGP certs. A bare key is not a cert. Let's not confuse terminology. > >For the purposes of storing records in DNS, is there a relevant distinction? > >I'd argue "absolutely not", especially since there is such a thing >as "Self signed cert": a self signed certificate is really no >different from a bare key except for some garbage around it for >formatting. I'd suggest that the SEC ADs will frown upon this cavalier use of terminology, which is inconsistent with RFC 4949 :-). A self-signed cert allows the signer to bind attributes to a public key, in a fashion that provides a consistency check, even though it does not provide a secure basis for authentication the identity of the Issuer/Subject. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A103A6B5E for ; Wed, 25 Aug 2010 18:00:46 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEHwfJz5pnlj for ; Wed, 25 Aug 2010 18:00:45 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 3EDA13A6A9C for ; Wed, 25 Aug 2010 18:00:45 -0700 (PDT) Received: from [192.168.0.221] (64-13-52-115.jck.clearwire-dns.net [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id AFFF622849AB; Wed, 25 Aug 2010 20:59:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <20100825233402.GA10325@odin.mars.sol> Date: Wed, 25 Aug 2010 21:01:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6D9D551A-EC0D-464A-A165-249ED9D7A834@kumari.net> References: <20100825233402.GA10325@odin.mars.sol> To: Scott Schmit X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Sample code X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 01:00:46 -0000 On Aug 25, 2010, at 7:34 PM, Scott Schmit wrote: > On Mon, Aug 23, 2010 at 04:04:43PM -0400, Richard L. Barnes wrote: >> // If we got a DNSSC-signed CERT record, add it to the SSL CA list >> if (result->secure && result->havedata) { >> // Read the X509 bytes into an OpenSSL X509 object >> // Skip 5 bytes of type/tag/algorithm in the rrdata >> unsigned char *cert_data =3D (unsigned char*) result->data[0] + = 5; >> int cert_len =3D result->len[0] - 5; >> X509* cert =3D d2i_X509(NULL, cert_data, cert_len); >> =09 >> // Mark the cert as a trusted CA cert >> SSL_add_client_CA(ctx, cert); >=20 > For what it's worth, depending on the context of this code, this could > be a very bad thing to do. For example, if this is a CA certificate = and > another site presents a certificate signed by this one (but without > DNSSEC, etc), it will be accepted as valid. Yes -- I don't think that this was intended to actually be used, but = rather just an example of how easily stuff like this can be done...=20 >=20 > In other words, I don't think you can validate the certificates from = DNS > without taking into account the domain they are bound to, or you lose > the benefit of this exercise. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAFC83A6A68 for ; Wed, 25 Aug 2010 16:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqnK3P4tvgri for ; Wed, 25 Aug 2010 16:53:26 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A92AC3A6A15 for ; Wed, 25 Aug 2010 16:53:26 -0700 (PDT) Received: by iwn3 with SMTP id 3so1115842iwn.31 for ; Wed, 25 Aug 2010 16:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7TAhVQs5EWU9UOH/Exnu0owXpR7Z5TZr5XPWAOoiZG8=; b=rwJnA3FcAwYD+hMBpEgVS1IixKpFvxIYai2jmT5zWap95pPUref5GdJEUzk6bbrW5q DLs9chOrWCnoNnCoiSncu9GP0M3lDQ5wD81Vt9LgxtK7QCHacRaJOPtsXlaQX22zwloZ SQ1XeKcplvV/+OxUvm2SsRwYoLphuseNpeVe4= 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:content-transfer-encoding; b=avPUKkuvsm3umKpGoxNOX1LXksbBf7770eytJAs0kpCe7Pa9aJ/iSvxR1SnUGiVk6l 0HyKz02j11uvB1X352DTlr0uej1TU8kRwivNNrHpVJttsiXd3Lp2S9J6InsJUOg/qAWf t40c41X4gSCcdpSePkAb0G9r5lzEWinwHEVwo= MIME-Version: 1.0 Received: by 10.231.33.131 with SMTP id h3mr8163874ibd.148.1282780438981; Wed, 25 Aug 2010 16:53:58 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Wed, 25 Aug 2010 16:53:58 -0700 (PDT) In-Reply-To: References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <84580414-1F3F-4B01-A41E-A0AB130D53A4@bbn.com> <7B492A8E-4C44-4EB8-8B9E-7F7067309653@icsi.berkeley.edu> Date: Wed, 25 Aug 2010 19:53:58 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 23:53:29 -0000 Precedent is already set on that one. CERT allows storage of raw keys. On Wed, Aug 25, 2010 at 7:11 PM, Stephen Kent wrote: > At 9:59 AM -0700 8/25/10, Nicholas Weaver wrote: >> >> On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote: >> ... >> >> And is there really a difference? =A0A "CERT" is simply the key-format >> desired by the application: SSL's CERTs are x509, but the "CERT" for SSH= is >> just the bare host key: this seems like a distinction without a differen= ce >> to me. > > A public key cert is a assertion of a binding between a public key and > a set of attributes, signed by an entity attesting to the accuracy of the > assertion. This characterization applies to X.509 certs and PGP certs. A > bare key is not a cert. =A0Let's not confuse terminology. > > Steve > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8048F3A689B for ; Wed, 25 Aug 2010 16:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.56 X-Spam-Level: X-Spam-Status: No, score=-100.56 tagged_above=-999 required=5 tests=[AWL=2.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqES+mB+KqFy for ; Wed, 25 Aug 2010 16:33:30 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 9B10C3A69DD for ; Wed, 25 Aug 2010 16:33:30 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id yhLf1e0081swQuc53na4Xr; Wed, 25 Aug 2010 23:34:04 +0000 Received: from olympia.mars.sol ([68.33.77.0]) by omta15.westchester.pa.mail.comcast.net with comcast id yna31e00L00PQ6U3bna3wu; Wed, 25 Aug 2010 23:34:04 +0000 Received: from olympia.mars.sol (localhost [127.0.0.1]) by olympia.mars.sol (8.14.4/8.14.3) with ESMTP id o7PNY2Z2010678; Wed, 25 Aug 2010 19:34:02 -0400 Received: (from draco@localhost) by olympia.mars.sol (8.14.4/8.14.4/Submit) id o7PNY2oH010677; Wed, 25 Aug 2010 19:34:02 -0400 Date: Wed, 25 Aug 2010 19:34:02 -0400 From: Scott Schmit To: "Richard L. Barnes" Message-ID: <20100825233402.GA10325@odin.mars.sol> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) Cc: keyassure@ietf.org Subject: Re: [keyassure] Sample code X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 23:33:33 -0000 On Mon, Aug 23, 2010 at 04:04:43PM -0400, Richard L. Barnes wrote: > // If we got a DNSSC-signed CERT record, add it to the SSL CA list > if (result->secure && result->havedata) { > // Read the X509 bytes into an OpenSSL X509 object > // Skip 5 bytes of type/tag/algorithm in the rrdata > unsigned char *cert_data = (unsigned char*) result->data[0] + 5; > int cert_len = result->len[0] - 5; > X509* cert = d2i_X509(NULL, cert_data, cert_len); > > // Mark the cert as a trusted CA cert > SSL_add_client_CA(ctx, cert); For what it's worth, depending on the context of this code, this could be a very bad thing to do. For example, if this is a CA certificate and another site presents a certificate signed by this one (but without DNSSEC, etc), it will be accepted as valid. In other words, I don't think you can validate the certificates from DNS without taking into account the domain they are bound to, or you lose the benefit of this exercise. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0A83A6A35 for ; Wed, 25 Aug 2010 16:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlPowpSAj2DL for ; Wed, 25 Aug 2010 16:30:04 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 50FEF3A688B for ; Wed, 25 Aug 2010 16:30:02 -0700 (PDT) Received: by gyh20 with SMTP id 20so526491gyh.31 for ; Wed, 25 Aug 2010 16:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Mj16uYigqcUKta1zqm0yjkJss6fQ6C7Noj/1nTBe5xM=; b=DVAy0dCxDxSvYwMZOc8gz1+AAGSdi/Avlb+eDLtFKeMhzoHgqUaa5o4i2rB5vKCV9v RZXIGpTiJ7VIXdJPn8h0nRlgFDM1j7LiDUtBCLUTOu7xhgxlluvrpxTnN7gjdgccStv3 CL6pnsLWVAkL1SqZro9oBlgqKyd845wYW1bt8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=eXwE1jE2+7eNpnm9JeomvBalkO1RB1IkTJb6z4Ry3fJZAsbphF24qmDD4SfW/vfnRD eu21m0dYbdO3GEQZAHKqQZfauZYvjr99rsmVKuqYVZLrNDTo3DydmgBwFdBXUETY73zl 3Puhj1jdmmasYf9Yi72T3r20QdSJctf2TexLw= Received: by 10.101.28.11 with SMTP id f11mr9775228anj.264.1282779034783; Wed, 25 Aug 2010 16:30:34 -0700 (PDT) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) by mx.google.com with ESMTPS id q7sm2883512anf.26.2010.08.25.16.30.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Aug 2010 16:30:33 -0700 (PDT) Sender: Nicholas Weaver Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Wed, 25 Aug 2010 16:30:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1C711173-CE4B-48A5-90A1-9D628382EDB4@ICSI.Berkeley.EDU> References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <84580414-1F3F-4B01-A41E-A0AB130D53A4@bbn.com> <7B492A8E-4C44-4EB8-8B9E-7F7067309653@icsi.berkeley.edu> To: Stephen Kent X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, Nicholas Weaver Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 23:30:11 -0000 On Aug 25, 2010, at 4:11 PM, Stephen Kent wrote: > At 9:59 AM -0700 8/25/10, Nicholas Weaver wrote: >> On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote: >> ... >>=20 >> And is there really a difference? A "CERT" is simply the key-format = desired by the application: SSL's CERTs are x509, but the "CERT" for SSH = is just the bare host key: this seems like a distinction without a = difference to me. >=20 > A public key cert is a assertion of a binding between a public key and > a set of attributes, signed by an entity attesting to the accuracy of = the assertion. This characterization applies to X.509 certs and PGP = certs. A bare key is not a cert. Let's not confuse terminology. For the purposes of storing records in DNS, is there a relevant = distinction? =20 I'd argue "absolutely not", especially since there is such a thing as = "Self signed cert": a self signed certificate is really no different = from a bare key except for some garbage around it for formatting. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C073A6B65 for ; Wed, 25 Aug 2010 16:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Wp8Sp75aR7t for ; Wed, 25 Aug 2010 16:27:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 26C903A6B60 for ; Wed, 25 Aug 2010 16:27:40 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37987 helo=[169.223.10.196]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoPO8-000AgK-1b; Wed, 25 Aug 2010 19:28:12 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <87hbii78bo.fsf@mocca.josefsson.org> References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <1C4ED82F-D56D-4362-914F-C41A44327901@ICSI.Berkeley.EDU> <87hbii78bo.fsf@mocca.josefsson.org> Date: Wed, 25 Aug 2010 19:18:30 -0400 To: Simon Josefsson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org, Nicholas Weaver Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 23:27:41 -0000 At 10:20 PM +0200 8/25/10, Simon Josefsson wrote: >... >I think it is important to shift the focus from how the wire syntax >should look like to how we really want this to be used and what >properties we think are important. The wire syntax is the simple part. > >/Simon I agree. It's critical to have a very clear characterization of what functions one wants to provide via DNS-supplied keys or certs, and why the use of DNS to effect this function is better than extant mechanisms. If we can't clearly articulate this, then it is not clear that a Wg should be created. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51083A6A7D for ; Wed, 25 Aug 2010 16:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWM+Av-S54X8 for ; Wed, 25 Aug 2010 16:27:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 1FF423A689B for ; Wed, 25 Aug 2010 16:27:34 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37987 helo=[169.223.10.196]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoPO2-000AgK-Bn; Wed, 25 Aug 2010 19:28:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7B492A8E-4C44-4EB8-8B9E-7F7067309653@icsi.berkeley.edu> References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <84580414-1F3F-4B01-A41E-A0AB130D53A4@bbn.com> <7B492A8E-4C44-4EB8-8B9E-7F7067309653@icsi.berkeley.edu> Date: Wed, 25 Aug 2010 19:11:11 -0400 To: Nicholas Weaver From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 23:27:35 -0000 At 9:59 AM -0700 8/25/10, Nicholas Weaver wrote: >On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote: >... > >And is there really a difference? A "CERT" is simply the key-format >desired by the application: SSL's CERTs are x509, but the "CERT" for >SSH is just the bare host key: this seems like a distinction without >a difference to me. A public key cert is a assertion of a binding between a public key and a set of attributes, signed by an entity attesting to the accuracy of the assertion. This characterization applies to X.509 certs and PGP certs. A bare key is not a cert. Let's not confuse terminology. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422463A6964 for ; Wed, 25 Aug 2010 15:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.276 X-Spam-Level: X-Spam-Status: No, score=-102.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSiQsZ7tIyIF for ; Wed, 25 Aug 2010 15:22:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 173E43A695D for ; Wed, 25 Aug 2010 15:22:22 -0700 (PDT) Received: from [192.1.255.185] (port=50061 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoOMw-000Bd5-DD; Wed, 25 Aug 2010 18:22:54 -0400 Message-Id: From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Aug 2010 18:22:53 -0400 References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <20100825214934.GA19156@shinkuro.com> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 22:22:23 -0000 Correct. But I'm not sure there's consensus on whether that's a problem that is in scope for this group. My opinion, as I've said before, is that the negotiation of SSL usage should be done at the application layer, not at the DNS layer. The notion of "SSL usage" can vary quite a bit from one application to another, and there are already several existing mechanisms for signaling secure transport in different protocols (obvious examples include URI schemes and the SIP transport=tls parameter). On Aug 25, 2010, at 6:14 PM, Phillip Hallam-Baker wrote: > TLS and most other security protocols already have mechanisms for that > type of parameter negotiation. Provided the credentials supplied are > trustworthy, the negotiation mechanism is sufficient to prevent an > in-protocol downgrade attack (e.g. use of md5in place of SHA256). > > The problem is that we do not have a mechanism for preventing > downgrade attack on the security protocol as a whole. We can stop the > use of substandard SSL but can't ensure that SSL is used at all. > > On Wed, Aug 25, 2010 at 5:54 PM, Richard L. Barnes > wrote: >> Works for me. I was going to suggest the slightly more compact >> phrase >> "authenticating services identified by domain name". >> >> FWIW, what I meant by the "negotiating crypto parameters" was >> something >> quite different, questions like "what cipher suite shall we use?", >> which >> aren't what we're talking about, but could also be construed as >> helping >> applications establish secure comms. >> >> >> >> On Aug 25, 2010, at 5:49 PM, Andrew Sullivan wrote: >> >>> On Wed, Aug 25, 2010 at 02:35:43PM -0700, Nicholas Weaver wrote: >>>> >>>> Why not "discovering and authenticating cryptographic material >>>> which is >>>> associated with a service located at a domain name"? >>>> >>> >>> Sure, that sounds right to me. >>> >>> A >>> >>> -- >>> Andrew Sullivan >>> ajs@shinkuro.com >>> Shinkuro, Inc. >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >> >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >> > > > > -- > Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C113A6A15 for ; Wed, 25 Aug 2010 15:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zK5yYAiBDxv for ; Wed, 25 Aug 2010 15:14:17 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D681A3A6926 for ; Wed, 25 Aug 2010 15:14:13 -0700 (PDT) Received: by iwn3 with SMTP id 3so1025244iwn.31 for ; Wed, 25 Aug 2010 15:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qSEVvpuCUJdedLWL3ny1xBn55KrdNq0ExEECcgRsxLg=; b=C/mUtw5ZoKZwpsRR70KATtMwaZWf0cqhEXTLJE5GxvmPM2SbPiI8j8PudN2DSkuMuR 3WNC8e7cI72wcKPlL8Nb/cWu5+tmwe56He+ikJcd7/k3EO8nUYdSfX0OsIDo0iVndrw4 HMZ8ngRXyOdezs6V6TZp3kwmO0x6AlTIsJly8= 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:content-transfer-encoding; b=HoBhxv8jSpv+Sc8qC/Fp1sUWF6RVrmUOnk7jw9fqB5AWWue7w4Kni9TJVWIkkGgSH4 6BL3fJKlnHvUMCQJ4bKq1xLp/0b8O/CJmNbDvcFD2pDeBm0Zf2sMhCAkwMTprIiWohYm kfD1bCrffR2tBddBmsagAMRvmQYypsxgffuQA= MIME-Version: 1.0 Received: by 10.231.191.74 with SMTP id dl10mr10946730ibb.157.1282774484449; Wed, 25 Aug 2010 15:14:44 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Wed, 25 Aug 2010 15:14:43 -0700 (PDT) In-Reply-To: References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <20100825214934.GA19156@shinkuro.com> Date: Wed, 25 Aug 2010 18:14:43 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 22:14:23 -0000 TLS and most other security protocols already have mechanisms for that type of parameter negotiation. Provided the credentials supplied are trustworthy, the negotiation mechanism is sufficient to prevent an in-protocol downgrade attack (e.g. use of md5in place of SHA256). The problem is that we do not have a mechanism for preventing downgrade attack on the security protocol as a whole. We can stop the use of substandard SSL but can't ensure that SSL is used at all. On Wed, Aug 25, 2010 at 5:54 PM, Richard L. Barnes wrote: > Works for me. =A0I was going to suggest the slightly more compact phrase > "authenticating services identified by domain name". > > FWIW, what I meant by the "negotiating crypto parameters" was something > quite different, questions like "what cipher suite shall we use?", which > aren't what we're talking about, but could also be construed as helping > applications establish secure comms. > > > > On Aug 25, 2010, at 5:49 PM, Andrew Sullivan wrote: > >> On Wed, Aug 25, 2010 at 02:35:43PM -0700, Nicholas Weaver wrote: >>> >>> Why not "discovering and authenticating cryptographic material which is >>> associated with a service located at a domain name"? >>> >> >> Sure, that sounds right to me. >> >> A >> >> -- >> Andrew Sullivan >> ajs@shinkuro.com >> Shinkuro, Inc. >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E353A6837 for ; Wed, 25 Aug 2010 15:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCn6v9dxeQNB for ; Wed, 25 Aug 2010 15:09:39 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BB5E83A63C9 for ; Wed, 25 Aug 2010 15:09:39 -0700 (PDT) Received: by iwn3 with SMTP id 3so1021531iwn.31 for ; Wed, 25 Aug 2010 15:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fp87Ye6ctP++HwjkWkNXBzzxisHZQR8jLCq1yK8YCp0=; b=AwCwdmpolejP+pu5ISqvr0PZrFeYEsvrLRzYPzlJsyKY4AMvci16Rv0HVEJU1GLMy+ vPsVhHoA+DYRxJxo7S6ZK5LB2ePqfSxJPM/pV8jPPIhpAJsGsvGnhPiVdo3tBlftjNrx Y8jpjTuXqSe4wsLFB4mQJonwudff8mYErQuGQ= 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:content-transfer-encoding; b=qRbZb5kLP1v8F1Nw2PHznt8rruPQLE8O29cvTaCGI4JHwaIt87xxGMm5UIUX7+n4qw oOSQE6Mgt96eTdZVuaz8c4oWq6y7aURZ1gC/f8/QsCTzCRzIF3anmI9m+UTnV6FfH0Hx Z71ooTMrfOCyPY7ArKmgxu2+SPuH/mE5MWIxU= MIME-Version: 1.0 Received: by 10.231.14.140 with SMTP id g12mr5360818iba.84.1282774198145; Wed, 25 Aug 2010 15:09:58 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Wed, 25 Aug 2010 15:09:57 -0700 (PDT) In-Reply-To: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> Date: Wed, 25 Aug 2010 18:09:57 -0400 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 22:09:42 -0000 This looks acceptable to me. Although I am currently working on a draft for the ESRV record, I consider that an experimental proposal. Although it is in some ways quite a bit easier to do since there is less legacy to work round. The approach I prefer there is to allocate a RR, perform some experiments with the general scheme as an 'Experimental' protocol and then start a standards track WG to develop specs to address discovery and security for specific groups of protocols (e.g. Web, Mail). On Wed, Aug 25, 2010 at 4:59 PM, Warren Kumari wrote: > So, a while back we had some discussions about a possible charter for a > possible working group. This discussion sort of veered off course, so thi= s > is a new thread, unencumbered by previous grumpiness... > > I have tried to distill essence from various folks comments and proposed > charters and come up with something that we can all (yeah, right!) agree > on... How do folk feel about the below? > > ----------------------------------- > Objective: > > Specify mechanisms and techniques that allow Internet applications to > establish cryptographically secured communications through use of > information distributed through the DNS. > > Problem Statement: > > Entities on the Internet are usually identified by domain names and formi= ng > a cryptographically secured connection to the entity requires the entity = to > authenticate its name. =A0For instance, in HTTPS, a server responding to = a > query for is expected to authenticate as > "www.example.com". =A0Security protocols such as TLS and IPsec accomplish= this > authentication by allowing an endpoint to prove ownership of a private ke= y > whose corresponding public key is somehow bound to the name being > authenticated. =A0As a pre-requisite for authentication, then, these prot= ocols > require a mechanism for bindings to be asserted between public keys and > domain names. > > DNSSEC provides a mechanism for a domain operator to sign DNS information > directly, using keys that are bound to the domain by the parent domain; > relying parties can continue this chain up to any trust anchor that they > accept. =A0In this way, bindings of keys to domains are asserted not by > external entities, but by the entities that operate the DNS. =A0In additi= on, > this technique inherently limits the scope of any given entity to the nam= es > in zones he controls. > > This working group will develop mechanisms for domain operators to presen= t > bindings between names within their control and public keys, in such a wa= y > that these bindings can be integrity-protected (and thus shown to be > authentically from the domain operator) using DNSSEC and used as a basis = for > authentication in protocols that use domain names as identifiers. =A0The = group > may also specify updates or clarifications to protocols to describe how > protocol entities discover and validate these bindings in the execution o= f > specific applications. > > --------------------------- > > I have attempted to pull bits from various people suggestions, and this i= s a > compromise -- I don't expect anyone to love it, but I hope that it at lea= st > acceptable to most. I'm hoping that we can keep this discussion on topic.= ... > > Whether or not this ends up being considered as a charter for a possible = WG > is not important, what is is that we have some rough idea of what we thin= k > we are hoping to accomplish... > > > W > > Below are the provided texts that I mainly pulled from (and then massaged= to > try and remove the point ends). > > -------------- > Ondrej Sury (apologies for pure ASCII munging) and myself had written the > original draft proposed charter as: > ---- > Problem Statement: > > The DNS Security Extensions are a collection of resource records and > protocol modifications that provide source authentication for the DNS. > > The DNSSEC signed root infrastructure provides a single, well published > trust-anchor and a method to build a chain of trust from an individual > resource record (RR) =A0to that TA. By leveraging this infrastructure we = can > securely bind information (such as a public key, certificate identifier, > etc) to a DNS name. > > Increasingly people would like to be able to take advantage of the > confidentiality and identity validation provided by protocols such as TLS= . > There are numerous barriers to this, including cost, ease of use, > complexity, certificate management, etc. By allowing users to securely > publish public key information we can allow users to easily and securely > make use of self-signed certificates. > > Currently, one of the issues limiting the use of self-signed certificates= is > the difficulty in key-distribution - it is infeasible to distribute a key > binding at the web scale. By providing a means to publish (and securely > validate) this information in the DNS, we allow for users to attest to th= e > validity of keying information and establish trust in the published publi= c > key. > > The DNSSEC root trust anchor can also be used for additional validation > during the current path validations. By validating that the =A0certificat= e > presented is the certificate identified by the DNS, we can provide > additional confidence that the client is connecting to the intended serve= r - > this helps alleviate concerns that a valid certificate has been obtained = by > an attacker (for example from a CA not used by the victim). > ----- > > Phillip Hallam-Baker has proposed: > ---- > Objective: > > Specify mechanisms that allow Internet applications to establish > cryptographically enhanced communications through use of information > distributed through the DNS. > > Problem Statement: > > Today the Internet is insecure by default and security is the > exception. If the security of the Internet is to be improved, security > must become the default. In particular modern computers have the > ability to employ cryptographic security enhancements with minimal or > negligible impact on performance, yet only a tiny proportion of > Internet traffic is encrypted or authenticated. > > One of the key weaknesses of the current Internet Public Key > Infrastructure (PKI) is that the most widely used Internet PKI is > based on the X.500 Directory scheme intended to support an entirely > different networking infrastructure. > > The naming infrastructure of the Internet is the DNS, not X.500. While > the PKIX specifications provide a means of mapping X.509v3 attributes > to DNS names there is currently no widely accepted, generalized means > of achieving the mapping from DNS names to X.509 certificates in > particular or to cryptographic keying material in general. DKIM and > SSH have demonstrated the utility of this approach in specific > domains, these specifications > > Recent progress in deployment of DNSSEC has renewed focus on the use > of the DNS naming system to support cryptographic operations. In > particular: > > =A0* Discovery of keying material by DNS name > =A0* Discovery of security criteria by DNS names > =A0* Verification of keying material through DNSSEC trust chains > > Scope: > > =A0* Use of existing security protocols with DNS established keys > =A0* Use of DNS to verify existing certificate / keysigning / security > assertion material formats > =A0* Means of verifying key/certificate chains using DNSSEC exclusively > =A0* Means of verifying key/certificate chains using DNSSEC in > combination with other existing means > > Out-Of-Scope: > > * Reason for choice of specific trust paths > * New formats for keying material (other than raw keys) > * New trust architectures (unless they can be expressed in existing forma= ts > > > ---- > And Richard L. Barnes has provided: > Objective: > > Specify mechanisms for Internet applications to use information distribut= ed > through the DNS to establish cryptographically assured bindings between > domain names and public keys. > > Problem Statement: > > Many Internet applications require protocol entities to authenticate that > they represent a certain domain name. =A0For instance, in HTTPS, a server > responding to a query for is expected to > authenticate as "www.example.com". =A0Security protocols such as TLS and = IPsec > accomplish this authentication by allowing an endpoint to prove ownership= of > a private key whose corresponding public key is somehow bound to the name > being authenticated. =A0As a pre-requisite for authentication, then, thes= e > protocols require a mechanism for bindings to be asserted between public > keys and domain names. > > In the past, these bindings have been asserted by parties external to the > DNS, using X.509 certificates. =A0A certification authority (CA) can crea= te > certificates that contain a domain name (e.g., as a Common Name or dNSNam= e > Subject Alternative Name) and a public key. =A0When a server presents thi= s > certificate and proves ownership of the private key, a relying party that > trusts the CA to authenticate domain ownership can be assured that the > server legitimately represents the domain. > > One problem with this model is that the CAs that are typically used have = no > relationship to the DNS infrastructure about which they are making > assertions. =A0Modern browsers and operating systems typically include mo= re > than a hundred CAs as trust anchors, any of which can create a certificat= e > for any domain name. > > DNSSEC provides a mechanism for a domain operator to sign DNS information > directly, using keys that are bound to the domain by the parent domain; > relying parties can continue this chain up to any trust anchor that they > accept. =A0In this way, bindings of keys to domains are asserted not by > external entities, but by the entities that operate the DNS. =A0In additi= on to > providing a more authoritative way of binding DNS names to keys, this > technique inherently limits the scope of any given entity to the names in > zones he controls. > > This working group will develop mechanisms for domain operators to presen= t > bindings between names within their control and public keys, in such a wa= y > that these bindings can be integrity-protected (and thus shown to be > authentically from the domain operator) using DNSSEC and used as a basis = for > authentication in protocols that use domain names as identifiers. =A0The = group > may also specify updates or clarifications to protocols to describe how > protocol entities discover and validate these bindings in the execution o= f a > specific application. > > Note that this working group is specifically focused on bindings between > domain names and public keys, rather than bindings between names and othe= r > sorts of information. =A0For example, an X.509 certificate can associate = many > types of information with its subject, including things like IP address > holdings and images of logos, as well as bindings to higher-layer identit= ies > (e.g., corporate names). =A0Mechanisms developed by this group will not b= e > focused on these additional data, only on public keys. =A0This basic bind= ing > might be used, however, to associate a domain name with rich data by > including the same public key in the certificate that is bound to the > domain. > > > > > > > -- > If the bad guys have copies of your MD5 passwords, then you have way bigg= er > problems than the bad guys having copies of your MD5 passwords. > -- Richard A Steenbergen > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F2A3A686E for ; Wed, 25 Aug 2010 14:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cJ2RP7OBIPZ for ; Wed, 25 Aug 2010 14:56:14 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 72B863A63C9 for ; Wed, 25 Aug 2010 14:56:14 -0700 (PDT) Received: by iwn3 with SMTP id 3so1010745iwn.31 for ; Wed, 25 Aug 2010 14:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=BCTwx94H4QE0LWkELINQFI4vpy/yr28XbLjEL1oMTMo=; b=jKt4rb5eFeMj6OJVzJbSO6XnFfweS8EHsd1WA2SM0P0jAeB1kHFQ+s2JAbHRObp4ya shqZXor1Lk3g1ja4QCya6fmZbY/TsseeEj0t54ntBn63H7ISxAR3qPiHNNWKaXTP0fmF 5nbhWDCv9sN5mrkGI/ajG3c0zqBsDZ7q1MxKk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=Y8UY1pTtrIC9xZlFTmpNFsoW/S++IKVEGQu/mUmBQNZWpMVdGdRc/hJ+G5fDITr0mW 6UiKQ41TOvtV+X+hhoV44m1PW69DgPUEJnNPj20rfp0nYsbaPwP/D7yR85Jk0WbZSw3Z vKGviM5KB6VEN7wA10B46yP3NAxH1Pd1QpEwE= Received: by 10.231.154.73 with SMTP id n9mr11032780ibw.10.1282773407017; Wed, 25 Aug 2010 14:56:47 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id j2sm1743614iba.12.2010.08.25.14.56.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Aug 2010 14:56:45 -0700 (PDT) Sender: Nicholas Weaver References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <1C4ED82F-D56D-4362-914F-C41A44327901@ICSI.Berkeley.EDU> <87hbii78bo.fsf@mocca.josefsson.org> <39729648-8313-4398-861A-B389B2F9F700@ICSI.Berkeley.EDU> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 25 Aug 2010 14:56:42 -0700 To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: Nicholas Weaver , keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:56:15 -0000 On Aug 25, 2010, at 2:47 PM, Phillip Hallam-Baker wrote: > On Wed, Aug 25, 2010 at 4:56 PM, Nicholas Weaver > wrote: >>=20 >> On Aug 25, 2010, at 1:47 PM, Phillip Hallam-Baker wrote: >>=20 >>> I agree with the principle but would like to change the emphasis: >>>=20 >>> First we need to decide what information we need to carry in DNS. >>>=20 >>> AFTER we have done that we can decide if CERT matches those needs. >>>=20 >>>=20 >>> What I do not want to do is look at the CERT record and work out how >>> we can apply it to our problem. It is quite likely it does not fit. >>=20 >> For carrying data as an authenticated unit ("this BLOB OF BITS is = authenticated by DNSSEC"), CERT is just fine: it accomplishes everything = thats needed: its extensible, the application's job is to treat it as = appropriate, and DNS sees just a binary blob. >>=20 >> Whats needed would be APIs and conventions to allow applications to = use that result. >>=20 >>=20 >> For carrying data only as a partially-authenticated blob ("this BLOB = OF BITS is authenticated by DNSSEC, but you should only rely on X, Y, Z = components"), yeah, that would probably be best with a new RR, or an = ancillary RR to a CERT record. BUT, and this is a big BUT, shouldn't = the application know that it should only rely on X, Y, and Z? >=20 > I agree! That is not the type of additional information I was = considering. >=20 > I want to digest the cert, the whole cert and nothing but the cert. >=20 >=20 > I was considering information of the type 'only use this with specific > protocols'. I don't think that really needs a new RR, but perhaps a naming = convention? EG _ssh.myhost.mydomain.com -> SSH public key _ssl.myhost.mydomain.com -> x509 certificate for SSL _auth_smtp.myhost... -> x509 certificate for authenticated SMTP _port_2121.myhost -> the SSH public key for connecting on port = 2121 ??? You need something like that anyway just to prevent spmaming too big a = results chain back? Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C2F3A6942 for ; Wed, 25 Aug 2010 14:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn38TK1IkWQg for ; Wed, 25 Aug 2010 14:54:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9B7D33A6B61 for ; Wed, 25 Aug 2010 14:54:23 -0700 (PDT) Received: from [192.1.255.185] (port=49952 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoNvk-000BA5-Ov; Wed, 25 Aug 2010 17:54:48 -0400 Message-Id: From: "Richard L. Barnes" To: Andrew Sullivan In-Reply-To: <20100825214934.GA19156@shinkuro.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Aug 2010 17:54:48 -0400 References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> <20100825214934.GA19156@shinkuro.com> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:54:28 -0000 Works for me. I was going to suggest the slightly more compact phrase "authenticating services identified by domain name". FWIW, what I meant by the "negotiating crypto parameters" was something quite different, questions like "what cipher suite shall we use?", which aren't what we're talking about, but could also be construed as helping applications establish secure comms. On Aug 25, 2010, at 5:49 PM, Andrew Sullivan wrote: > On Wed, Aug 25, 2010 at 02:35:43PM -0700, Nicholas Weaver wrote: >> >> Why not "discovering and authenticating cryptographic material >> which is associated with a service located at a domain name"? >> > > Sure, that sounds right to me. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270973A69ED for ; Wed, 25 Aug 2010 14:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.327 X-Spam-Level: X-Spam-Status: No, score=-101.327 tagged_above=-999 required=5 tests=[AWL=1.272, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bx5ohr90l7Vy for ; Wed, 25 Aug 2010 14:49:12 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 90C1A3A6837 for ; Wed, 25 Aug 2010 14:49:11 -0700 (PDT) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3DAEB1ECB41D for ; Wed, 25 Aug 2010 21:49:43 +0000 (UTC) Date: Wed, 25 Aug 2010 17:49:34 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20100825214934.GA19156@shinkuro.com> Mail-Followup-To: keyassure@ietf.org References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:49:13 -0000 On Wed, Aug 25, 2010 at 02:35:43PM -0700, Nicholas Weaver wrote: > > Why not "discovering and authenticating cryptographic material which is associated with a service located at a domain name"? > Sure, that sounds right to me. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0035D3A6A5C for ; Wed, 25 Aug 2010 14:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbWGvhw8Mriq for ; Wed, 25 Aug 2010 14:46:49 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 270D83A6A77 for ; Wed, 25 Aug 2010 14:46:49 -0700 (PDT) Received: by iwn3 with SMTP id 3so1003003iwn.31 for ; Wed, 25 Aug 2010 14:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AMu61jCc6FZYd4WwqRwAeHImexwdLoeWKk8nrdGRx7Q=; b=jn20SYCONGXD+RvRswuFjAHyIXoJQtukOXVhtV1WRpYdwOYym0zAA9YIubPSfE/PNs 8NOU/Bp1FAG0J/Od7ZdI4mm5Tr2SW2AIduR3oSvERU+3X5PklOd3WdOSGhyj3Ak3KOzf /PwF5zQ7PV2U1jag8ro9JfJSJ4dzAu+d33HoQ= 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:content-transfer-encoding; b=D2AwLJe2u/w5FirIHShwkYMqUXwwR8YuDha5SgXUHYvu/EMFyGU3vK2Iqf0ICpoYwe /gkPvshTaE+JCg7NuC0IVjZ+ObV98Xv/hhTOeelRns3FYAHU3amN/r3zPmRsAjrdZARU hz9IpeWKHuwt8LsJrnj7zC0YtOEgD+xNczcs4= MIME-Version: 1.0 Received: by 10.231.146.141 with SMTP id h13mr10832710ibv.1.1282772840978; Wed, 25 Aug 2010 14:47:20 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Wed, 25 Aug 2010 14:47:20 -0700 (PDT) In-Reply-To: <39729648-8313-4398-861A-B389B2F9F700@ICSI.Berkeley.EDU> References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <1C4ED82F-D56D-4362-914F-C41A44327901@ICSI.Berkeley.EDU> <87hbii78bo.fsf@mocca.josefsson.org> <39729648-8313-4398-861A-B389B2F9F700@ICSI.Berkeley.EDU> Date: Wed, 25 Aug 2010 17:47:20 -0400 Message-ID: From: Phillip Hallam-Baker To: Nicholas Weaver Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:46:51 -0000 On Wed, Aug 25, 2010 at 4:56 PM, Nicholas Weaver wrote: > > On Aug 25, 2010, at 1:47 PM, Phillip Hallam-Baker wrote: > >> I agree with the principle but would like to change the emphasis: >> >> First we need to decide what information we need to carry in DNS. >> >> AFTER we have done that we can decide if CERT matches those needs. >> >> >> What I do not want to do is look at the CERT record and work out how >> we can apply it to our problem. It is quite likely it does not fit. > > For carrying data as an authenticated unit ("this BLOB OF BITS is authent= icated by DNSSEC"), CERT is just fine: it accomplishes everything thats nee= ded: its extensible, the application's job is to treat it as appropriate, a= nd DNS sees just a binary blob. > > Whats needed would be APIs and conventions to allow applications to use t= hat result. > > > For carrying data only as a partially-authenticated blob ("this BLOB OF B= ITS is authenticated by DNSSEC, but you should only rely on X, Y, Z compone= nts"), yeah, that would probably be best with a new RR, or an ancillary RR = to a CERT record. =A0BUT, and this is a big BUT, shouldn't the application = know that it should only rely on X, Y, and Z? I agree! That is not the type of additional information I was considering. I want to digest the cert, the whole cert and nothing but the cert. I was considering information of the type 'only use this with specific protocols'. Now one way out of this might well be to consider that the exact same issue already exists in X.509v3 certs and a CA has to consider the fact when they sign the certificate. So one approach would be to require the party inserting the cert into the zone to consider whether all the asserted purposes are acceptable to them. I am not trying to be a PITA on this. This is cutting through a lot of PKIX and TLS work and in addition to the specifications we have to consider there is also a body of 'lore' - i.e. deployed legacy stuff. It may actually be safer to use keyassure to assure CA certs that are then used to authenticate the end entity certs. We know how to do that. Then you want to put the whole CA cert in the CERT record. --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0CD3A6B55 for ; Wed, 25 Aug 2010 14:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvsWp2rf-EZH for ; Wed, 25 Aug 2010 14:38:25 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 519BF3A6B46 for ; Wed, 25 Aug 2010 14:37:14 -0700 (PDT) Received: by pvg7 with SMTP id 7so479435pvg.31 for ; Wed, 25 Aug 2010 14:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=nsLOBkkkreTII+pDpoLyK8SrrhRKYS82qix5xTb6Yb8=; b=ppSE0V+UcBD/bPiUetq9ul67bihpMZokTS71sdGHWoqqWTXy+rQEOrI6EfBBvl/7hg 3pXtYdWHYnEhfRCaofP/4aXP/KeFIQngzjGgL7sZh6/MLkdYQjv50+6j85qClRpHYo/3 hGdGCVRyMJD7uQLsvzsgnFkOtkyXx862CQ0ac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=L6e499ODLG30xnZ5O18bTwemxTJX2/Sehoh7GZZCNIM+WgZ/LHOMnZdoSsssTEhWhk PCOCxGzTInIe3eSYJHhUEe6IjdC1ScfZ2ZlSOuk0hX60iM+MSPF2g7qXzuMmKQ15Smo9 3qDDAssH/GcdXDJqSRjGwR7QLNoH/3Gh4kI1g= Received: by 10.114.109.18 with SMTP id h18mr10209288wac.66.1282772146902; Wed, 25 Aug 2010 14:35:46 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id c10sm3032347wam.1.2010.08.25.14.35.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Aug 2010 14:35:45 -0700 (PDT) Sender: Nicholas Weaver References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> <20100825213056.GA19087@shinkuro.com> In-Reply-To: <20100825213056.GA19087@shinkuro.com> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <349A43F8-F507-4359-AA3F-3E8545EA0C46@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 25 Aug 2010 14:35:43 -0700 To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:38:43 -0000 On Aug 25, 2010, at 2:30 PM, Andrew Sullivan wrote: > On Wed, Aug 25, 2010 at 05:14:59PM -0400, Richard L. Barnes wrote: >> I would prefer the Objective be tightened a little to focus on =20 >> authenticating domain names, as opposed to, say, negotiating crypto =20= >=20 > What do you mwan "authenticating"? If what you want to do is ensure > yourself that you're actually going to the right address, you can do > that now. That's all DNSSEC does. Why not "discovering and authenticating cryptographic material which is = associated with a service located at a domain name"? >=20 > I think the goal here is to make sure that the certificate you're > using is the right one for the service you're trying to talk to. The > traditional way to do that is already well-defined. The current work > is aimed at providing an alternate way to do that, using the > assurances you can get from the DNS (using DNSSEC). So I think the > talk of "negotiating crypto parameters" and such is about right. >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B753A6837 for ; Wed, 25 Aug 2010 14:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.236 X-Spam-Level: X-Spam-Status: No, score=-101.236 tagged_above=-999 required=5 tests=[AWL=1.363, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkEXZOjd8CMk for ; Wed, 25 Aug 2010 14:30:29 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 929793A68D8 for ; Wed, 25 Aug 2010 14:30:28 -0700 (PDT) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D00381ECB41D for ; Wed, 25 Aug 2010 21:31:00 +0000 (UTC) Date: Wed, 25 Aug 2010 17:30:56 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20100825213056.GA19087@shinkuro.com> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:30:46 -0000 On Wed, Aug 25, 2010 at 05:14:59PM -0400, Richard L. Barnes wrote: > I would prefer the Objective be tightened a little to focus on > authenticating domain names, as opposed to, say, negotiating crypto What do you mwan "authenticating"? If what you want to do is ensure yourself that you're actually going to the right address, you can do that now. That's all DNSSEC does. I think the goal here is to make sure that the certificate you're using is the right one for the service you're trying to talk to. The traditional way to do that is already well-defined. The current work is aimed at providing an alternate way to do that, using the assurances you can get from the DNS (using DNSSEC). So I think the talk of "negotiating crypto parameters" and such is about right. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8893A6964 for ; Wed, 25 Aug 2010 14:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wErBn3nzWm9B for ; Wed, 25 Aug 2010 14:14:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id ABE7B3A6942 for ; Wed, 25 Aug 2010 14:14:28 -0700 (PDT) Received: from [192.1.255.185] (port=49793 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoNJE-000ASc-V4; Wed, 25 Aug 2010 17:15:01 -0400 Message-Id: <2D5A80D8-C5BE-4336-817C-B1A067C439B0@bbn.com> From: "Richard L. Barnes" To: Warren Kumari In-Reply-To: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Aug 2010 17:14:59 -0400 References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:14:31 -0000 Best attempt so far! The problem statement looks fine to me. My only (minor) comment is that I would prefer the Objective be tightened a little to focus on authenticating domain names, as opposed to, say, negotiating crypto parameters. Suggested text (just off the top of my head): " Specify mechanisms and techniques that allow Internet applications to establish cryptographically secured communications by using information distributed through the DNS to support domain name authentication. " On Aug 25, 2010, at 4:59 PM, Warren Kumari wrote: > So, a while back we had some discussions about a possible charter > for a possible working group. This discussion sort of veered off > course, so this is a new thread, unencumbered by previous > grumpiness... > > I have tried to distill essence from various folks comments and > proposed charters and come up with something that we can all (yeah, > right!) agree on... How do folk feel about the below? > > ----------------------------------- > Objective: > > Specify mechanisms and techniques that allow Internet applications > to establish cryptographically secured communications through use of > information distributed through the DNS. > > Problem Statement: > > Entities on the Internet are usually identified by domain names and > forming a cryptographically secured connection to the entity > requires the entity to authenticate its name. For instance, in > HTTPS, a server responding to a query for > is expected to authenticate as "www.example.com". Security > protocols such as TLS and IPsec accomplish this authentication by > allowing an endpoint to prove ownership of a private key whose > corresponding public key is somehow bound to the name being > authenticated. As a pre-requisite for authentication, then, these > protocols require a mechanism for bindings to be asserted between > public keys and domain names. > > DNSSEC provides a mechanism for a domain operator to sign DNS > information directly, using keys that are bound to the domain by the > parent domain; relying parties can continue this chain up to any > trust anchor that they accept. In this way, bindings of keys to > domains are asserted not by external entities, but by the entities > that operate the DNS. In addition, this technique inherently limits > the scope of any given entity to the names in zones he controls. > > This working group will develop mechanisms for domain operators to > present bindings between names within their control and public keys, > in such a way that these bindings can be integrity-protected (and > thus shown to be authentically from the domain operator) using > DNSSEC and used as a basis for authentication in protocols that use > domain names as identifiers. The group may also specify updates or > clarifications to protocols to describe how protocol entities > discover and validate these bindings in the execution of specific > applications. > > --------------------------- > > I have attempted to pull bits from various people suggestions, and > this is a compromise -- I don't expect anyone to love it, but I hope > that it at least acceptable to most. I'm hoping that we can keep > this discussion on topic.... > > Whether or not this ends up being considered as a charter for a > possible WG is not important, what is is that we have some rough > idea of what we think we are hoping to accomplish... > > > W > > Below are the provided texts that I mainly pulled from (and then > massaged to try and remove the point ends). > > -------------- > Ondrej Sury (apologies for pure ASCII munging) and myself had > written the original draft proposed charter as: > ---- > Problem Statement: > > The DNS Security Extensions are a collection of resource records and > protocol modifications that provide source authentication for the DNS. > > The DNSSEC signed root infrastructure provides a single, well > published trust-anchor and a method to build a chain of trust from > an individual resource record (RR) to that TA. By leveraging this > infrastructure we can securely bind information (such as a public > key, certificate identifier, etc) to a DNS name. > > Increasingly people would like to be able to take advantage of the > confidentiality and identity validation provided by protocols such > as TLS. There are numerous barriers to this, including cost, ease of > use, complexity, certificate management, etc. By allowing users to > securely publish public key information we can allow users to easily > and securely make use of self-signed certificates. > > Currently, one of the issues limiting the use of self-signed > certificates is the difficulty in key-distribution - it is > infeasible to distribute a key binding at the web scale. By > providing a means to publish (and securely validate) this > information in the DNS, we allow for users to attest to the validity > of keying information and establish trust in the published public key. > > The DNSSEC root trust anchor can also be used for additional > validation during the current path validations. By validating that > the certificate presented is the certificate identified by the DNS, > we can provide additional confidence that the client is connecting > to the intended server - this helps alleviate concerns that a valid > certificate has been obtained by an attacker (for example from a CA > not used by the victim). > ----- > > Phillip Hallam-Baker has proposed: > ---- > Objective: > > Specify mechanisms that allow Internet applications to establish > cryptographically enhanced communications through use of information > distributed through the DNS. > > Problem Statement: > > Today the Internet is insecure by default and security is the > exception. If the security of the Internet is to be improved, security > must become the default. In particular modern computers have the > ability to employ cryptographic security enhancements with minimal or > negligible impact on performance, yet only a tiny proportion of > Internet traffic is encrypted or authenticated. > > One of the key weaknesses of the current Internet Public Key > Infrastructure (PKI) is that the most widely used Internet PKI is > based on the X.500 Directory scheme intended to support an entirely > different networking infrastructure. > > The naming infrastructure of the Internet is the DNS, not X.500. While > the PKIX specifications provide a means of mapping X.509v3 attributes > to DNS names there is currently no widely accepted, generalized means > of achieving the mapping from DNS names to X.509 certificates in > particular or to cryptographic keying material in general. DKIM and > SSH have demonstrated the utility of this approach in specific > domains, these specifications > > Recent progress in deployment of DNSSEC has renewed focus on the use > of the DNS naming system to support cryptographic operations. In > particular: > > * Discovery of keying material by DNS name > * Discovery of security criteria by DNS names > * Verification of keying material through DNSSEC trust chains > > Scope: > > * Use of existing security protocols with DNS established keys > * Use of DNS to verify existing certificate / keysigning / security > assertion material formats > * Means of verifying key/certificate chains using DNSSEC exclusively > * Means of verifying key/certificate chains using DNSSEC in > combination with other existing means > > Out-Of-Scope: > > * Reason for choice of specific trust paths > * New formats for keying material (other than raw keys) > * New trust architectures (unless they can be expressed in existing > formats > > > ---- > And Richard L. Barnes has provided: > Objective: > > Specify mechanisms for Internet applications to use information > distributed through the DNS to establish cryptographically assured > bindings between domain names and public keys. > > Problem Statement: > > Many Internet applications require protocol entities to authenticate > that they represent a certain domain name. For instance, in HTTPS, > a server responding to a query for is > expected to authenticate as "www.example.com". Security protocols > such as TLS and IPsec accomplish this authentication by allowing an > endpoint to prove ownership of a private key whose corresponding > public key is somehow bound to the name being authenticated. As a > pre-requisite for authentication, then, these protocols require a > mechanism for bindings to be asserted between public keys and domain > names. > > In the past, these bindings have been asserted by parties external > to the DNS, using X.509 certificates. A certification authority > (CA) can create certificates that contain a domain name (e.g., as a > Common Name or dNSName Subject Alternative Name) and a public key. > When a server presents this certificate and proves ownership of the > private key, a relying party that trusts the CA to authenticate > domain ownership can be assured that the server legitimately > represents the domain. > > One problem with this model is that the CAs that are typically used > have no relationship to the DNS infrastructure about which they are > making assertions. Modern browsers and operating systems typically > include more than a hundred CAs as trust anchors, any of which can > create a certificate for any domain name. > > DNSSEC provides a mechanism for a domain operator to sign DNS > information directly, using keys that are bound to the domain by the > parent domain; relying parties can continue this chain up to any > trust anchor that they accept. In this way, bindings of keys to > domains are asserted not by external entities, but by the entities > that operate the DNS. In addition to providing a more authoritative > way of binding DNS names to keys, this technique inherently limits > the scope of any given entity to the names in zones he controls. > > This working group will develop mechanisms for domain operators to > present bindings between names within their control and public keys, > in such a way that these bindings can be integrity-protected (and > thus shown to be authentically from the domain operator) using > DNSSEC and used as a basis for authentication in protocols that use > domain names as identifiers. The group may also specify updates or > clarifications to protocols to describe how protocol entities > discover and validate these bindings in the execution of a specific > application. > > Note that this working group is specifically focused on bindings > between domain names and public keys, rather than bindings between > names and other sorts of information. For example, an X.509 > certificate can associate many types of information with its > subject, including things like IP address holdings and images of > logos, as well as bindings to higher-layer identities (e.g., > corporate names). Mechanisms developed by this group will not be > focused on these additional data, only on public keys. This basic > binding might be used, however, to associate a domain name with rich > data by including the same public key in the certificate that is > bound to the domain. > > > > > > > -- > If the bad guys have copies of your MD5 passwords, then you have way > bigger problems than the bad guys having copies of your MD5 passwords. > -- Richard A Steenbergen > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DEB43A68E3 for ; Wed, 25 Aug 2010 14:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.131 X-Spam-Level: X-Spam-Status: No, score=-101.131 tagged_above=-999 required=5 tests=[AWL=1.468, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAKnvsAsNQUP for ; Wed, 25 Aug 2010 14:05:25 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 24B353A68A7 for ; Wed, 25 Aug 2010 14:05:25 -0700 (PDT) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id AEB9A1ECB41E for ; Wed, 25 Aug 2010 21:05:57 +0000 (UTC) Date: Wed, 25 Aug 2010 17:05:56 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20100825210556.GL17552@shinkuro.com> References: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:05:26 -0000 On Wed, Aug 25, 2010 at 04:59:01PM -0400, Warren Kumari wrote: > I have tried to distill essence from various folks comments and proposed > charters and come up with something that we can all (yeah, right!) agree > on... How do folk feel about the below? I think it's a reasonably generic outline of the things we're trying to solve. I think it does not prejudge the solution that will be reached, in the sense that it doesn't restrict the details of the eventual approach. I think it _does_ prejudge the solution in the sense that it restricts scope to the specific DNS-based approaches under discussion, rather than opening the discussion up to every possible authentication mechanism. So I think it's about right. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C29E3A6949 for ; Wed, 25 Aug 2010 13:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.489 X-Spam-Level: X-Spam-Status: No, score=-101.489 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9UjVgJan0oT for ; Wed, 25 Aug 2010 13:58:30 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 843B13A6903 for ; Wed, 25 Aug 2010 13:58:30 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id 4947C2284A45; Wed, 25 Aug 2010 16:57:26 -0400 (EDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 0343C22849AB for ; Wed, 25 Aug 2010 16:57:24 -0400 (EDT) Message-Id: <588F1D39-42B5-4CF4-BD37-5BCB9C008AC3@kumari.net> From: Warren Kumari To: keyassure@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Aug 2010 16:59:01 -0400 X-Mailer: Apple Mail (2.936) Subject: [keyassure] Poking the charter bear.... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 20:58:32 -0000 So, a while back we had some discussions about a possible charter for a possible working group. This discussion sort of veered off course, so this is a new thread, unencumbered by previous grumpiness... I have tried to distill essence from various folks comments and proposed charters and come up with something that we can all (yeah, right!) agree on... How do folk feel about the below? ----------------------------------- Objective: Specify mechanisms and techniques that allow Internet applications to establish cryptographically secured communications through use of information distributed through the DNS. Problem Statement: Entities on the Internet are usually identified by domain names and forming a cryptographically secured connection to the entity requires the entity to authenticate its name. For instance, in HTTPS, a server responding to a query for is expected to authenticate as "www.example.com". Security protocols such as TLS and IPsec accomplish this authentication by allowing an endpoint to prove ownership of a private key whose corresponding public key is somehow bound to the name being authenticated. As a pre-requisite for authentication, then, these protocols require a mechanism for bindings to be asserted between public keys and domain names. DNSSEC provides a mechanism for a domain operator to sign DNS information directly, using keys that are bound to the domain by the parent domain; relying parties can continue this chain up to any trust anchor that they accept. In this way, bindings of keys to domains are asserted not by external entities, but by the entities that operate the DNS. In addition, this technique inherently limits the scope of any given entity to the names in zones he controls. This working group will develop mechanisms for domain operators to present bindings between names within their control and public keys, in such a way that these bindings can be integrity-protected (and thus shown to be authentically from the domain operator) using DNSSEC and used as a basis for authentication in protocols that use domain names as identifiers. The group may also specify updates or clarifications to protocols to describe how protocol entities discover and validate these bindings in the execution of specific applications. --------------------------- I have attempted to pull bits from various people suggestions, and this is a compromise -- I don't expect anyone to love it, but I hope that it at least acceptable to most. I'm hoping that we can keep this discussion on topic.... Whether or not this ends up being considered as a charter for a possible WG is not important, what is is that we have some rough idea of what we think we are hoping to accomplish... W Below are the provided texts that I mainly pulled from (and then massaged to try and remove the point ends). -------------- Ondrej Sury (apologies for pure ASCII munging) and myself had written the original draft proposed charter as: ---- Problem Statement: The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. The DNSSEC signed root infrastructure provides a single, well published trust-anchor and a method to build a chain of trust from an individual resource record (RR) to that TA. By leveraging this infrastructure we can securely bind information (such as a public key, certificate identifier, etc) to a DNS name. Increasingly people would like to be able to take advantage of the confidentiality and identity validation provided by protocols such as TLS. There are numerous barriers to this, including cost, ease of use, complexity, certificate management, etc. By allowing users to securely publish public key information we can allow users to easily and securely make use of self-signed certificates. Currently, one of the issues limiting the use of self-signed certificates is the difficulty in key-distribution - it is infeasible to distribute a key binding at the web scale. By providing a means to publish (and securely validate) this information in the DNS, we allow for users to attest to the validity of keying information and establish trust in the published public key. The DNSSEC root trust anchor can also be used for additional validation during the current path validations. By validating that the certificate presented is the certificate identified by the DNS, we can provide additional confidence that the client is connecting to the intended server - this helps alleviate concerns that a valid certificate has been obtained by an attacker (for example from a CA not used by the victim). ----- Phillip Hallam-Baker has proposed: ---- Objective: Specify mechanisms that allow Internet applications to establish cryptographically enhanced communications through use of information distributed through the DNS. Problem Statement: Today the Internet is insecure by default and security is the exception. If the security of the Internet is to be improved, security must become the default. In particular modern computers have the ability to employ cryptographic security enhancements with minimal or negligible impact on performance, yet only a tiny proportion of Internet traffic is encrypted or authenticated. One of the key weaknesses of the current Internet Public Key Infrastructure (PKI) is that the most widely used Internet PKI is based on the X.500 Directory scheme intended to support an entirely different networking infrastructure. The naming infrastructure of the Internet is the DNS, not X.500. While the PKIX specifications provide a means of mapping X.509v3 attributes to DNS names there is currently no widely accepted, generalized means of achieving the mapping from DNS names to X.509 certificates in particular or to cryptographic keying material in general. DKIM and SSH have demonstrated the utility of this approach in specific domains, these specifications Recent progress in deployment of DNSSEC has renewed focus on the use of the DNS naming system to support cryptographic operations. In particular: * Discovery of keying material by DNS name * Discovery of security criteria by DNS names * Verification of keying material through DNSSEC trust chains Scope: * Use of existing security protocols with DNS established keys * Use of DNS to verify existing certificate / keysigning / security assertion material formats * Means of verifying key/certificate chains using DNSSEC exclusively * Means of verifying key/certificate chains using DNSSEC in combination with other existing means Out-Of-Scope: * Reason for choice of specific trust paths * New formats for keying material (other than raw keys) * New trust architectures (unless they can be expressed in existing formats ---- And Richard L. Barnes has provided: Objective: Specify mechanisms for Internet applications to use information distributed through the DNS to establish cryptographically assured bindings between domain names and public keys. Problem Statement: Many Internet applications require protocol entities to authenticate that they represent a certain domain name. For instance, in HTTPS, a server responding to a query for is expected to authenticate as "www.example.com". Security protocols such as TLS and IPsec accomplish this authentication by allowing an endpoint to prove ownership of a private key whose corresponding public key is somehow bound to the name being authenticated. As a pre-requisite for authentication, then, these protocols require a mechanism for bindings to be asserted between public keys and domain names. In the past, these bindings have been asserted by parties external to the DNS, using X.509 certificates. A certification authority (CA) can create certificates that contain a domain name (e.g., as a Common Name or dNSName Subject Alternative Name) and a public key. When a server presents this certificate and proves ownership of the private key, a relying party that trusts the CA to authenticate domain ownership can be assured that the server legitimately represents the domain. One problem with this model is that the CAs that are typically used have no relationship to the DNS infrastructure about which they are making assertions. Modern browsers and operating systems typically include more than a hundred CAs as trust anchors, any of which can create a certificate for any domain name. DNSSEC provides a mechanism for a domain operator to sign DNS information directly, using keys that are bound to the domain by the parent domain; relying parties can continue this chain up to any trust anchor that they accept. In this way, bindings of keys to domains are asserted not by external entities, but by the entities that operate the DNS. In addition to providing a more authoritative way of binding DNS names to keys, this technique inherently limits the scope of any given entity to the names in zones he controls. This working group will develop mechanisms for domain operators to present bindings between names within their control and public keys, in such a way that these bindings can be integrity-protected (and thus shown to be authentically from the domain operator) using DNSSEC and used as a basis for authentication in protocols that use domain names as identifiers. The group may also specify updates or clarifications to protocols to describe how protocol entities discover and validate these bindings in the execution of a specific application. Note that this working group is specifically focused on bindings between domain names and public keys, rather than bindings between names and other sorts of information. For example, an X.509 certificate can associate many types of information with its subject, including things like IP address holdings and images of logos, as well as bindings to higher-layer identities (e.g., corporate names). Mechanisms developed by this group will not be focused on these additional data, only on public keys. This basic binding might be used, however, to associate a domain name with rich data by including the same public key in the certificate that is bound to the domain. -- If the bad guys have copies of your MD5 passwords, then you have way bigger problems than the bad guys having copies of your MD5 passwords. -- Richard A Steenbergen Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B043A68BC for ; Wed, 25 Aug 2010 13:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql2Ihm75TcFy for ; Wed, 25 Aug 2010 13:55:47 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 6FF473A6829 for ; Wed, 25 Aug 2010 13:55:47 -0700 (PDT) Received: by pzk6 with SMTP id 6so447745pzk.31 for ; Wed, 25 Aug 2010 13:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=aQGUFoH3WdToTUzQIhBO/J0Yjm+Q2zdrRxp9AwjLlAo=; b=JCFI/2ZoHnO8GSXFQTCgADIqQnNhBo3F2gFNHuYWrDypMMckufSttkB0vjj6ehHSTj 2/8s9zp8Sd4yHOmF9hb6oQDaIdK87IrGOLKkhtBuNn0KMizxqoKsVFq6a1CG8EcbQPu4 IjnYxB14SKurGiU3xbewEMTJIEN7PvVmXGf04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=ehSci3LOJJP0sVHvL7WfDAAoFoqkePnB06ulHdDGqsI9MRbdR+uW9UmIzkQYAtLIFF adRpcWX9Nkrh+KfF8IF5xZkmUHBY+G/RNbQY/7NEF3U0bYH0zIB4/e2ESKYRcydkfCK3 1OVGcwT2+dmXT9Qo5+ZrLW/Je45dyc1MqaL7E= Received: by 10.142.174.13 with SMTP id w13mr2241945wfe.126.1282769775473; Wed, 25 Aug 2010 13:56:15 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id 33sm1982530wfg.9.2010.08.25.13.56.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Aug 2010 13:56:13 -0700 (PDT) Sender: Nicholas Weaver References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <1C4ED82F-D56D-4362-914F-C41A44327901@ICSI.Berkeley.EDU> <87hbii78bo.fsf@mocca.josefsson.org> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <39729648-8313-4398-861A-B389B2F9F700@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 25 Aug 2010 13:56:10 -0700 To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: Nicholas Weaver , keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 20:55:48 -0000 On Aug 25, 2010, at 1:47 PM, Phillip Hallam-Baker wrote: > I agree with the principle but would like to change the emphasis: >=20 > First we need to decide what information we need to carry in DNS. >=20 > AFTER we have done that we can decide if CERT matches those needs. >=20 >=20 > What I do not want to do is look at the CERT record and work out how > we can apply it to our problem. It is quite likely it does not fit. For carrying data as an authenticated unit ("this BLOB OF BITS is = authenticated by DNSSEC"), CERT is just fine: it accomplishes everything = thats needed: its extensible, the application's job is to treat it as = appropriate, and DNS sees just a binary blob. Whats needed would be APIs and conventions to allow applications to use = that result. For carrying data only as a partially-authenticated blob ("this BLOB OF = BITS is authenticated by DNSSEC, but you should only rely on X, Y, Z = components"), yeah, that would probably be best with a new RR, or an = ancillary RR to a CERT record. BUT, and this is a big BUT, shouldn't = the application know that it should only rely on X, Y, and Z? Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D313A68A7 for ; Wed, 25 Aug 2010 13:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQsUkVa1NQaA for ; Wed, 25 Aug 2010 13:47:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 1FA6F3A6927 for ; Wed, 25 Aug 2010 13:47:22 -0700 (PDT) Received: by gyh20 with SMTP id 20so447346gyh.31 for ; Wed, 25 Aug 2010 13:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lTdz49uo011K1xB7F2EL6LDvEDgn0CvcAVMqkGdFKRA=; b=B/uRG58E6DDay5TTtMiaw+zxocbydd9cLeVQjKwyd4lSWg2yVpD5ynNn1ABFLD7tF8 HjbPXF7GUSm4ykLorZvMHdppRi6L3GAzro3kYOLeAuxa5QV4T8RuSWg8wXU33AZUXU8B 6jj0RwodEcbulmjrfExAvpaIKFRqxsTlMfonM= 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:content-transfer-encoding; b=k1Ay0atWCIlIwUyldyYIobCZk/9QQWVMBptyuAJ3bgsB0O2A/ajll0YRTXNn607bA0 ZBjpGaRIjig8kb3lIdqK0Mm2u9sRWy5FFsHtfGyImpRrjeA4VaWRvb+IImq8EPrciRSd 4Yn8DuixA3TMp3c7t3HpP+dQMXuZ67+TmwErc= MIME-Version: 1.0 Received: by 10.151.99.10 with SMTP id b10mr5750125ybm.54.1282769274625; Wed, 25 Aug 2010 13:47:54 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Wed, 25 Aug 2010 13:47:54 -0700 (PDT) In-Reply-To: <87hbii78bo.fsf@mocca.josefsson.org> References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <1C4ED82F-D56D-4362-914F-C41A44327901@ICSI.Berkeley.EDU> <87hbii78bo.fsf@mocca.josefsson.org> Date: Wed, 25 Aug 2010 16:47:54 -0400 Message-ID: From: Phillip Hallam-Baker To: Simon Josefsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 20:47:39 -0000 I agree with the principle but would like to change the emphasis: First we need to decide what information we need to carry in DNS. AFTER we have done that we can decide if CERT matches those needs. What I do not want to do is look at the CERT record and work out how we can apply it to our problem. It is quite likely it does not fit. On Wed, Aug 25, 2010 at 4:20 PM, Simon Josefsson wrot= e: > Nicholas Weaver writes: > >>> I thought this group was to work on a good standard for those >>> applications, and that those who want to use certs, can stick with usin= g >>> RFC 4398 (or non-DNS based validation, eg EVR) >> >> In many ways, I somewhat agree, but for a different reason: CERT RRs >> are just a perfectly fine container class. =A0We probably don't need new >> RR types. >> >> What we need is ways of using such container classes with DNSSEC: this >> doesn't add any new to-the-wire representatiton, but does require new >> ways (APIs, naming conventions) of using the DNSSEC data, both at a >> low level (APIs) and high level ("cookbook recipies"). > > +1 > > I think it is important to shift the focus from how the wire syntax > should look like to how we really want this to be used and what > properties we think are important. =A0The wire syntax is the simple part. > > /Simon > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E784B3A6937 for ; Wed, 25 Aug 2010 13:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.692 X-Spam-Level: X-Spam-Status: No, score=-102.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wl2uxQFPGJAq for ; Wed, 25 Aug 2010 13:20:26 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 267D23A6903 for ; Wed, 25 Aug 2010 13:20:25 -0700 (PDT) Received: from mocca (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7PKKkr0005038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 25 Aug 2010 22:20:49 +0200 From: Simon Josefsson To: Nicholas Weaver References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <1C4ED82F-D56D-4362-914F-C41A44327901@ICSI.Berkeley.EDU> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100825:keyassure@ietf.org::H9mx3P3sjMkjKU9+:wMD X-Hashcash: 1:22:100825:paul@xelerance.com::BVqki6h9I8k1aTef:7IPX X-Hashcash: 1:22:100825:nweaver@icsi.berkeley.edu::W6gLNaFCyb/MD5LC:8sHs Date: Wed, 25 Aug 2010 22:20:43 +0200 In-Reply-To: <1C4ED82F-D56D-4362-914F-C41A44327901@ICSI.Berkeley.EDU> (Nicholas Weaver's message of "Mon, 23 Aug 2010 08:39:45 -0700") Message-ID: <87hbii78bo.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 20:20:28 -0000 Nicholas Weaver writes: >> I thought this group was to work on a good standard for those >> applications, and that those who want to use certs, can stick with using >> RFC 4398 (or non-DNS based validation, eg EVR) > > In many ways, I somewhat agree, but for a different reason: CERT RRs > are just a perfectly fine container class. We probably don't need new > RR types. > > What we need is ways of using such container classes with DNSSEC: this > doesn't add any new to-the-wire representatiton, but does require new > ways (APIs, naming conventions) of using the DNSSEC data, both at a > low level (APIs) and high level ("cookbook recipies"). +1 I think it is important to shift the focus from how the wire syntax should look like to how we really want this to be used and what properties we think are important. The wire syntax is the simple part. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839503A6948 for ; Wed, 25 Aug 2010 11:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Pd3wcdAHapO for ; Wed, 25 Aug 2010 11:03:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 22CB13A68BF for ; Wed, 25 Aug 2010 11:03:43 -0700 (PDT) Received: from [192.1.255.185] (port=52384 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoKKd-0005BG-N4; Wed, 25 Aug 2010 14:04:15 -0400 Message-Id: From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Aug 2010 14:04:14 -0400 References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <8FD4736C-443F-44C9-A7A0-60C895410C16@bbn.com> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] On eliminating ports X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 18:03:44 -0000 Not talking about delegation here -- the starting assumption is that =20 all the services are using the same domain name. For delegation =20 considerations, see [1]. The scenario here is where example.com hosts: EntityA on http://example.com:44300/ EntityB on http://example.com:44301/ If the server is poorly configured (so that you get (e) as below), =20 then unless you can distinguish which cert goes with which port, =20 EntityA can provide an EV cert for EntityB without the client noticing. You might arrive at these port-wise services via an SRV or NAPTR =20 record, but those should be authenticated themselves, so that the end =20= server can authenticate as itself. In other words, there are two =20 separate authentications going on here: 1. Authenticate delegation record 2. Authenticate remote service The first one is done with DNSSEC or DNA [1]; the second one is what =20 we're doing here. Again, IMO, this case is deep in the corner, but included for =20 completeness. --Richard [1] On Aug 25, 2010, at 1:45 PM, Phillip Hallam-Baker wrote: > The issue of delegation is a difficult one and might well be something > that ESRV or SRV is used to address. > > The discovery of the delegation relationship is going to be discovered > during service discovery, i.e. before we start the TCP connection or > SSL tunnel. > > If I can sign a DNSSEC zone record to say 'for email service for > hallambaker.com see gmail.com', then the service can and should expect > to see an SSL cert presented for gmail.com as opposed to > hallambaker.com. > > One of the issues I am trying to deal with here is the fact that the > existing mechanism for SSL domain name binding does not work as it > should. > > > In order to claim that there is a system here it is going to be > necessary to provide a pretty exhaustive explanation of how this all > works with Web and with Mail. > > On Wed, Aug 25, 2010 at 1:15 PM, Richard L. Barnes =20= > wrote: >> I think there's something missing here. You also run into problems =20= >> if (!a >> && b && c) and: >> >> d) The client is making decisions based on certificate attributes =20 >> other than >> domain names >> >> e) One service can access another's private key >> >> If (!a && b && c && d && e), then one service can present another =20 >> service's >> certificate, influencing client behavior. You could envision =20 >> problems >> arising from differences in issuer (EV vs. DV). In some sense, =20 >> this isn't a >> huge issue, since a lot of attributes are effectively the same for =20= >> different >> processes on the same machine, but there are still some trouble =20 >> cases. For >> example, there are two entities with EV certs on the same server, =20 >> with the >> same domain-name, one service would be able to present the other's =20= >> EV cert, >> and the client would not be able to distinguish. [1] >> >> I'll leave it as an exercise to the reader to determine how =20 >> practical this >> scenario is. In all candor, I'm mainly including it for =20 >> completeness; it >> doesn't seem like a huge risk to me. >> >> --Richard >> >> >> [1] Digression: THe CA/Browser Forum document describing EV certs =20 >> says that >> the domain name field in an EV cert "MUST contain one or more host =20= >> domain >> name(s) owned or controlled by the Subject and to be associated with >> Subject=92s server. Such server MAY be owned and operated by the =20 >> Subject or >> another entity (e.g., a hosting service)." This situation would =20 >> arise in >> the latter case, where another entity owns and operates the zone in >> question. >> >> >> >> On Aug 25, 2010, at 12:10 PM, Paul Hoffman wrote: >> >>> First off, one of the more common criticisms we got on the -00 was =20= >>> the >>> complication of the ports, so this is not clear-cut. Having said =20 >>> that, I >>> believe the *only* situation where specifying the ports in the =20 >>> TSLFP CERT >>> request is valuable is when all the following are true: >>> >>> a) There are more than five or so servers on different ports on >>> server.example.com >>> >>> b) Each server uses a different certificate >>> >>> c) The users always go to the tuple { dns=3Dserver.example.com && =20= >>> port=3Dnnn } >>> >>> If (a) and (b) are true but (c) is not, for example if there are =20 >>> addional >>> names such as www.example.com and imap.example.com for the various =20= >>> servers, >>> there is no problem because the user will look up the individual =20 >>> name. >>> >>> If (a) and (c) are true but (b) is not, there is no problem =20 >>> because the >>> user will get a useful response regardless of the port they go to. >>> >>> If (b) and (c) are true but (a) is not, then the client software =20 >>> needs >>> compare the hash of the cert gotten in TLS against a small number =20= >>> of hashes. >>> The only problem here is that the request for the TLSFP CERT RR is =20= >>> somewhat >>> large. >>> >>> In what real-world use cases is this a problem? >>> >>> --Paul Hoffman, Director >>> --VPN Consortium >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >> >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >> > > > > --=20 > Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA053A6B26 for ; Wed, 25 Aug 2010 10:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhbJ2mPTt1Vd for ; Wed, 25 Aug 2010 10:45:20 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 391C13A68C0 for ; Wed, 25 Aug 2010 10:45:20 -0700 (PDT) Received: by pxi6 with SMTP id 6so372574pxi.31 for ; Wed, 25 Aug 2010 10:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i8qFJzzWJgL2+JOXqHDyDYCcwf9UR7mbrMoqnnu1/RA=; b=MUAolkZdhXfPip4JrrIRExX+WmoC3EuMkk73Jwo9EEmsddylP2QSbjcsfpYWefplSE R1JPucPmuoTqgo1gVZHW6+/Wa2tDuGy0qKEypHiGDYORcxN7Bo3d1xUfg66pzMYEbApm 6q2rn6Gzzzyzrm6Q5JG4RoTQVgJJNTETJCQek= 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:content-transfer-encoding; b=hRHzEd8vspS41/qIzQZFm4xbVt4rXe1bXO1w2VtDrnJ6JBmJFvY0nZAFfieYTJ7HQn IdnUUR9D7RSq90MuWN1I61N8dwvAC3+qOFV0OS15o6/evNLdJ50q0iofRIBu+fQObCem E/R6Oc3nW2iLVpmNrQarg2qWeEqgpKh+P6gCs= MIME-Version: 1.0 Received: by 10.114.103.3 with SMTP id a3mr9931524wac.34.1282758351056; Wed, 25 Aug 2010 10:45:51 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Wed, 25 Aug 2010 10:45:50 -0700 (PDT) In-Reply-To: <8FD4736C-443F-44C9-A7A0-60C895410C16@bbn.com> References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <8FD4736C-443F-44C9-A7A0-60C895410C16@bbn.com> Date: Wed, 25 Aug 2010 13:45:50 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] On eliminating ports X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 17:45:21 -0000 The issue of delegation is a difficult one and might well be something that ESRV or SRV is used to address. The discovery of the delegation relationship is going to be discovered during service discovery, i.e. before we start the TCP connection or SSL tunnel. If I can sign a DNSSEC zone record to say 'for email service for hallambaker.com see gmail.com', then the service can and should expect to see an SSL cert presented for gmail.com as opposed to hallambaker.com. One of the issues I am trying to deal with here is the fact that the existing mechanism for SSL domain name binding does not work as it should. In order to claim that there is a system here it is going to be necessary to provide a pretty exhaustive explanation of how this all works with Web and with Mail. On Wed, Aug 25, 2010 at 1:15 PM, Richard L. Barnes wrote: > I think there's something missing here. =A0You also run into problems if = (!a > && b && c) and: > > d) The client is making decisions based on certificate attributes other t= han > domain names > > e) One service can access another's private key > > If (!a && b && c && d && e), then one service can present another service= 's > certificate, influencing client behavior. =A0You could envision problems > arising from differences in issuer (EV vs. DV). =A0In some sense, this is= n't a > huge issue, since a lot of attributes are effectively the same for differ= ent > processes on the same machine, but there are still some trouble cases. = =A0For > example, there are two entities with EV certs on the same server, with th= e > same domain-name, one service would be able to present the other's EV cer= t, > and the client would not be able to distinguish. =A0[1] > > I'll leave it as an exercise to the reader to determine how practical thi= s > scenario is. =A0In all candor, I'm mainly including it for completeness; = it > doesn't seem like a huge risk to me. > > --Richard > > > [1] Digression: THe CA/Browser Forum document describing EV certs says th= at > the domain name field in an EV cert "MUST contain one or more host domain > name(s) owned or controlled by the Subject and to be associated with > Subject=92s server. =A0Such server MAY be owned and operated by the Subje= ct or > another entity (e.g., a hosting service)." =A0This situation would arise = in > the latter case, where another entity owns and operates the zone in > question. > > > > On Aug 25, 2010, at 12:10 PM, Paul Hoffman wrote: > >> First off, one of the more common criticisms we got on the -00 was the >> complication of the ports, so this is not clear-cut. Having said that, I >> believe the *only* situation where specifying the ports in the TSLFP CER= T >> request is valuable is when all the following are true: >> >> a) There are more than five or so servers on different ports on >> server.example.com >> >> b) Each server uses a different certificate >> >> c) The users always go to the tuple { dns=3Dserver.example.com && port= =3Dnnn } >> >> If (a) and (b) are true but (c) is not, for example if there are addiona= l >> names such as www.example.com and imap.example.com for the various serve= rs, >> there is no problem because the user will look up the individual name. >> >> If (a) and (c) are true but (b) is not, there is no problem because the >> user will get a useful response regardless of the port they go to. >> >> If (b) and (c) are true but (a) is not, then the client software needs >> compare the hash of the cert gotten in TLS against a small number of has= hes. >> The only problem here is that the request for the TLSFP CERT RR is somew= hat >> large. >> >> In what real-world use cases is this a problem? >> >> --Paul Hoffman, Director >> --VPN Consortium >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0772A3A68CD for ; Wed, 25 Aug 2010 10:21:43 -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.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfJ1AI1SH5Rz for ; Wed, 25 Aug 2010 10:21:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id CA8653A67F8 for ; Wed, 25 Aug 2010 10:21:41 -0700 (PDT) Received: from [192.1.255.185] (port=51826 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoJfy-00053W-9S; Wed, 25 Aug 2010 13:22:14 -0400 Message-Id: <98CBAE14-5F69-4696-962A-619247DAC37B@bbn.com> From: "Richard L. Barnes" To: Jakob Schlyter In-Reply-To: <68933CBA-6EA2-494D-BE1C-AB16BD6EB9FF@kirei.se> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Aug 2010 13:22:13 -0400 References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <84580414-1F3F-4B01-A41E-A0AB130D53A4@bbn.com> <68933CBA-6EA2-494D-BE1C-AB16BD6EB9FF@kirei.se> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 17:21:43 -0000 Responses inline. >> It's actually kind of a big reduction in triviality. The SSL >> libraries right now are set up so that users provide trust anchors >> in the form of certs instead of fingerprints. (At least, I'm not >> aware of any that do the latter.) If you require fingerprint >> matching in the validation, you have to start mucking around with >> TLS libraries, instead of just being able to make use of existing >> libraries. > > It is not trust anchors that are published in the DNS, it is the > very same cert. If we would publish trust anchors, only self-signed > certificates could be validated, no? There's some misunderstanding of terms here: A trust anchor is any point where the client doesn't feel that it needs to continue validation. (In particular, it doesn't have to be self-signed.) So in the context of the domain being validated, the cert presented is a trust anchor -- if the server presents it and it matches, there's no further validation necesary. >> The one thing you could do to hack around this is do post-hoc >> checking: Accept the cert to establish the TLS connection, then >> validate it and terminate the connection if the validation fails. >> But in order to make that secure, you basically have to put the >> connection on hold while you do the validation, which is a little >> weird. And that in addition to the sort of philosophical point >> that it seems like the TLS negotiation should fail if you're not >> ultimately going to accept it. > > In the latest version of our draft we propose that the key > association is performed first, optionally followed by traditional > PKIX validation. I'll have to go read that :) >> Volume II: Certs vs. keys >> >> A related discussion we should be having is whether we want to be >> talking about certs or keys in the DNS. (Whether directly, e.g., as >> a subjectPublicKeyInfo structure, or hashed.) It seems to me that >> working with keys would be more flexible, since you wouldn't be >> bound to a single cert. That is, you could present multiple certs >> without having to have multiple RRs, and you could change your cert >> without updating the DNS (e.g., to renew it). > > With keys (or hash of key), any CA could pull that key and sign in > (with the key association still valid). With a hash-of-cert, that is > not possible (which I think is a feature for people depending on > things like EV). I'm not sure what the risk is here. If a CA takes my public key and issues a cert to some attacker, the attacker can't use it to masquerade as me, since he doesn't have my private key. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985823A67F8 for ; Wed, 25 Aug 2010 10:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBoTqYxYgJLK for ; Wed, 25 Aug 2010 10:14:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6F8863A68E9 for ; Wed, 25 Aug 2010 10:14:48 -0700 (PDT) Received: from [192.1.255.185] (port=51792 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoJZJ-0004vE-3U; Wed, 25 Aug 2010 13:15:21 -0400 Message-Id: <8FD4736C-443F-44C9-A7A0-60C895410C16@bbn.com> From: "Richard L. Barnes" To: Paul Hoffman In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Aug 2010 13:15:19 -0400 References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] On eliminating ports X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 17:14:52 -0000 I think there's something missing here. You also run into problems if =20= (!a && b && c) and: d) The client is making decisions based on certificate attributes =20 other than domain names e) One service can access another's private key If (!a && b && c && d && e), then one service can present another =20 service's certificate, influencing client behavior. You could =20 envision problems arising from differences in issuer (EV vs. DV). In =20= some sense, this isn't a huge issue, since a lot of attributes are =20 effectively the same for different processes on the same machine, but =20= there are still some trouble cases. For example, there are two =20 entities with EV certs on the same server, with the same domain-name, =20= one service would be able to present the other's EV cert, and the =20 client would not be able to distinguish. [1] I'll leave it as an exercise to the reader to determine how practical =20= this scenario is. In all candor, I'm mainly including it for =20 completeness; it doesn't seem like a huge risk to me. --Richard [1] Digression: THe CA/Browser Forum document describing EV certs says =20= that the domain name field in an EV cert "MUST contain one or more =20 host domain name(s) owned or controlled by the Subject and to be =20 associated with Subject=92s server. Such server MAY be owned and =20 operated by the Subject or another entity (e.g., a hosting service)." =20= This situation would arise in the latter case, where another entity =20 owns and operates the zone in question. On Aug 25, 2010, at 12:10 PM, Paul Hoffman wrote: > First off, one of the more common criticisms we got on the -00 was =20 > the complication of the ports, so this is not clear-cut. Having said =20= > that, I believe the *only* situation where specifying the ports in =20 > the TSLFP CERT request is valuable is when all the following are true: > > a) There are more than five or so servers on different ports on =20 > server.example.com > > b) Each server uses a different certificate > > c) The users always go to the tuple { dns=3Dserver.example.com && =20 > port=3Dnnn } > > If (a) and (b) are true but (c) is not, for example if there are =20 > addional names such as www.example.com and imap.example.com for the =20= > various servers, there is no problem because the user will look up =20 > the individual name. > > If (a) and (c) are true but (b) is not, there is no problem because =20= > the user will get a useful response regardless of the port they go to. > > If (b) and (c) are true but (a) is not, then the client software =20 > needs compare the hash of the cert gotten in TLS against a small =20 > number of hashes. The only problem here is that the request for the =20= > TLSFP CERT RR is somewhat large. > > In what real-world use cases is this a problem? > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE443A6B29 for ; Wed, 25 Aug 2010 10:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_20=-0.74, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR0clzIIcu4k for ; Wed, 25 Aug 2010 10:10:22 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 564AE3A6B3C for ; Wed, 25 Aug 2010 10:10:21 -0700 (PDT) Received: by iwn3 with SMTP id 3so826828iwn.31 for ; Wed, 25 Aug 2010 10:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fng1tNrntlbS21Q6ZIOts02XLN2GCA8LoIKcwUXXIOg=; b=g2i1XLRMQnNjU6nlsSytZhqEBlRFkzigdjBEGQbsEqj9LwNur9taIwHHMUIuEnAqJh feIBkKQK/cf8VWRpSmrPTkdZ0Oxn6/U0tvfcPuaIXJKEb09UK1385j9uwpaanYgBxm6G OXYMyN506/OCR1KiVtexanPdpc1XNCDZZ4nko= 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:content-transfer-encoding; b=aaeUeAv2SOZoEaw4NEjxGydDFvi2FFamouBMzfC6gGUVZGUJM6WPFk/QQ9sqxh5wRZ nwsZyjFvrVKmOwq8Jo9BCyobih7+wt68cha/B7LIXgiv9Y+c3hGiRsB6PFCv9kf93hXE Htt8aR1GC3olJ0Kut0YBHhO2vXdKuT8cFbqPc= MIME-Version: 1.0 Received: by 10.231.167.67 with SMTP id p3mr10510445iby.20.1282756253673; Wed, 25 Aug 2010 10:10:53 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Wed, 25 Aug 2010 10:10:53 -0700 (PDT) In-Reply-To: References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> Date: Wed, 25 Aug 2010 13:10:53 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] On eliminating ports X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 17:10:27 -0000 Well there was various criticism. In particular I don't think you have appreciated the difference between the use of port numbers to differentiate between certs in discovery and their use to restrict use of a cert to a specific service and/or protocol. Let us take as a use case the need to support google.com ten years from now when it is supporting 1000 applications. It is not going to be possible for people to remember the names of all those applications so the simplest approach will be to have them all use google.com as the domain name. This approach is certainly implicit in the SRV approach. It is clearly not going to be practical for all those services to use the same cert. It is certainly not desirable to do so. So I consider any attempt to use the domain alone as the discover mechanism to be impractical. Even if you could transport 1000 certs in one DNS record, you would not want to try. We already have a solution for differentiating discovery in DKIM - key tags= . In the case of SSL you always know the cert before you need to validate it. So I would differentiate the task of cert discovery and the task of determining if a cert is acceptable for a specific purpose. Cert discovery is relatively easy. We just need a means of uniquely identifying the cert. That can be provided * [By a hash of the cert itself] * By a digest function on the cert itself * By new data provided in the cert * [By data provided in the TLS transaction] * (Might be possible to use the cert serial number which should be unique) I have used square brackets for the ones I consider unacceptable. Why use a hash rather than a digest? I can't think of a good reason. I don't want to have to touch the Web server code to enable this, IIS has a several year development cycle and many people can't upgrade their Apache without upgrading lots of other stuff thats likely to break. Most people seem to think that a digest function on the cert using the digest function used to sign it works for them. _b5Y6eWCdCwrrODTG+lJ3iob7Ks3+ybatOSlpWGMU8k0.example.com CERT .... We can truncate to fit into a 64 octet label without issue. The second issue is how to restrict the use of the cert to a specific purpose. Here we have the following possibilities: * data in the certificate * data in the label field of the DNS record * data in the data field of the DNS record * data in a companion record to CERT * use a new record rather than reuse CERT * pretending this is not a security problem * require use of SRV and a separate host name per certificate If you want to reuse CERT, the data field is not available and if you are going to use a companion record then you might as well abandon the attempt to extend CERT. Try to pretend it is not a problem and people will rightly scream that it i= s. So taking out those we have: * data in the certificate * data in the label field of the DNS record * require use of SRV and a separate host name per certificate * use a new record rather than reuse CERT I don't like the first since we are now talking about putting a fairly complicated statement that can change over the cert validity period into the cert. I have no problem generating a random identifier and slamming it in, but I am nervous about anything requiring thought. The label field might have been practical if we didn't also need the digest in the tag. If we were to fully secure both the protocol and the port we would have: _8000,_http._tcp._b5Y6eWCdCwrrODTG_lJ3iob7Ks3_ybatOSlpWGMU8k0.example.com CERT .... We could trim this a little if we can use the serial #: _8000,_http._tcp._-F8gAyPA_mLT-mb75FGgnQ.example.com CERT .... If we insist on using SRV we have fundamentally changed HTTP in order to make the key assurance work. Even though I am proposing to do just that as an option, doing that right is research and key assurance should not be research fifteen years after we started doing SSL. I am quite happy to do research to make a protocol work better, but building research on research is a Error 33 from Parc. We should not do research for the sake of saving a DNS resource record. Reuse of CERT is looking much less attractive to me. I had been convinced to use it since it really does solve some problems, particularly in the general case where we are not using SSL. But it has parameters I do not want and lacks parameters I think we need. This would give us: _F8gAyPA_mLT-mb75FGgnQ.example.com APPKEY "port=3D80 protocol=3D_http._tcp digest=3Db5Y6eWCdCwrrODTG+lJ3iob7Ks3+ybatOSlpWGMU8k0=3D" We could add in specifications to allow a link to a CERT record and/or a ur= i. On Wed, Aug 25, 2010 at 12:10 PM, Paul Hoffman wrot= e: > First off, one of the more common criticisms we got on the -00 was the co= mplication of the ports, so this is not clear-cut. Having said that, I beli= eve the *only* situation where specifying the ports in the TSLFP CERT reque= st is valuable is when all the following are true: > > a) There are more than five or so servers on different ports on server.ex= ample.com > > b) Each server uses a different certificate > > c) The users always go to the tuple { dns=3Dserver.example.com && port=3D= nnn } > > If (a) and (b) are true but (c) is not, for example if there are addional= names such as www.example.com and imap.example.com for the various servers= , there is no problem because the user will look up the individual name. > > If (a) and (c) are true but (b) is not, there is no problem because the u= ser will get a useful response regardless of the port they go to. > > If (b) and (c) are true but (a) is not, then the client software needs co= mpare the hash of the cert gotten in TLS against a small number of hashes. = The only problem here is that the request for the TLSFP CERT RR is somewhat= large. > > In what real-world use cases is this a problem? > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52DCD3A6A43 for ; Wed, 25 Aug 2010 10:03:44 -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_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aSd2j9SaCH5 for ; Wed, 25 Aug 2010 10:03:43 -0700 (PDT) Received: from mail.kirei.se (wagaya.kirei.se [91.206.174.10]) by core3.amsl.com (Postfix) with ESMTP id CBE683A6B4D for ; Wed, 25 Aug 2010 10:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kirei.se; s=wagaya20060620; t=1282755837; bh=6rUJg1vYlbe/J4NvpuEsC8/rjjp//X4SlzHrmCzqrOI=; h=Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tdBSgTA23oOGuoERw2fvx7+p/JzdAbsqSPF/Sp0hSBlZUeZeJxc2X1+ziEjrbFQqG RPp9n7L4Ja6f8CJRXlOWo+6OaYX9B5QTRMCXyQL7hDFkTcgEh4pPkPqQH+OS3k8Jix TbdRCk4jCQ9SYVJIUSNHNu1kS1+683y2azryeI5I= Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <84580414-1F3F-4B01-A41E-A0AB130D53A4@bbn.com> Date: Wed, 25 Aug 2010 19:03:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <68933CBA-6EA2-494D-BE1C-AB16BD6EB9FF@kirei.se> References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <84580414-1F3F-4B01-A41E-A0AB130D53A4@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 17:03:44 -0000 On 25 aug 2010, at 18.50, Richard L. Barnes wrote: > It's actually kind of a big reduction in triviality. The SSL = libraries right now are set up so that users provide trust anchors in = the form of certs instead of fingerprints. (At least, I'm not aware of = any that do the latter.) If you require fingerprint matching in the = validation, you have to start mucking around with TLS libraries, instead = of just being able to make use of existing libraries. It is not trust anchors that are published in the DNS, it is the very = same cert. If we would publish trust anchors, only self-signed = certificates could be validated, no? > The one thing you could do to hack around this is do post-hoc = checking: Accept the cert to establish the TLS connection, then validate = it and terminate the connection if the validation fails. But in order = to make that secure, you basically have to put the connection on hold = while you do the validation, which is a little weird. And that in = addition to the sort of philosophical point that it seems like the TLS = negotiation should fail if you're not ultimately going to accept it. In the latest version of our draft we propose that the key association = is performed first, optionally followed by traditional PKIX validation. > Volume II: Certs vs. keys >=20 > A related discussion we should be having is whether we want to be = talking about certs or keys in the DNS. (Whether directly, e.g., as a = subjectPublicKeyInfo structure, or hashed.) It seems to me that working = with keys would be more flexible, since you wouldn't be bound to a = single cert. That is, you could present multiple certs without having = to have multiple RRs, and you could change your cert without updating = the DNS (e.g., to renew it). With keys (or hash of key), any CA could pull that key and sign in (with = the key association still valid). With a hash-of-cert, that is not = possible (which I think is a feature for people depending on things like = EV). jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C0B43A6B54 for ; Wed, 25 Aug 2010 10:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.993 X-Spam-Level: X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NtY9RoC-q5a for ; Wed, 25 Aug 2010 10:01:46 -0700 (PDT) Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id 2090F3A6B50 for ; Wed, 25 Aug 2010 10:01:46 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7PH2IKU001539 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 25 Aug 2010 13:02:18 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7PH2HpF019538 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 25 Aug 2010 13:02:18 -0400 (EDT) Message-Id: <2E25F54C-4EB4-4D45-93DE-297A495A4BAD@princeton.edu> From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: <7B492A8E-4C44-4EB8-8B9E-7F7067309653@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Aug 2010 13:02:15 -0400 References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <84580414-1F3F-4B01-A41E-A0AB130D53A4@bbn.com> <7B492A8E-4C44-4EB8-8B9E-7F7067309653@icsi.berkeley.edu> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6084 signatures=637985 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008250121 Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 17:01:47 -0000 On Aug 25, 2010, at 12:59 PM, Nicholas Weaver wrote: > On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote: >> Volume II: Certs vs. keys >> >> A related discussion we should be having is whether we want to be >> talking about certs or keys in the DNS. (Whether directly, e.g., as >> a subjectPublicKeyInfo structure, or hashed.) It seems to me that >> working with keys would be more flexible, since you wouldn't be >> bound to a single cert. That is, you could present multiple certs >> without having to have multiple RRs, and you could change your cert >> without updating the DNS (e.g., to renew it). > > I don't see how this would be the case: you have N keys or N certs > means N records for the host. > > And is there really a difference? A "CERT" is simply the key-format > desired by the application: SSL's CERTs are x509, but the "CERT" for > SSH is just the bare host key: this seems like a distinction without > a difference to me. Many certs may share the same public/private key pair. It matters if what people are proposing is hashing one particular key- format, especially if that format includes things that are not assertable by the person who controls the zone (unless the spec explicitly outlines which elements are assertable and which are not). Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E133A69F1 for ; Wed, 25 Aug 2010 09:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IYDmehB7jev for ; Wed, 25 Aug 2010 09:58:50 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 633C33A6879 for ; Wed, 25 Aug 2010 09:58:50 -0700 (PDT) Received: by pvg7 with SMTP id 7so372232pvg.31 for ; Wed, 25 Aug 2010 09:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=ifFXJWE0ShLhunlU6P11YN0VkIHlFMId3QkmGeYX53g=; b=ZQhdESDoM9+jNZS7hlWW4GrvW79TmPwvskrDrXbMAu2nBy2QiAKoelRBAK9sBbgnGF Rz6VuQjFDDi8ku180TD/m6KznlIc+qmRl98sShvmFOQtqjKx1Uwd7ZcLqjfiql7h8OY8 Nrjs94HNRStlH/q4io2jqGDLRwkURAVeXb//4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=p5UUOCyQotuyj6nkqyBDngvdlyx2AFuq1wqQ+XBeqNuBZbvI5eXcA+UEqAXA2XQxmM 6bZ7b/hjL8t92xflM/3vbEM3ip3S5XUsNwXcjcqqRu6KlrhKChH98rarGggBqO39KDcG iD30vbdqoF9zqMUwn4Lm4SY4jF6D5U06L7IAQ= Received: by 10.114.61.8 with SMTP id j8mr9754791waa.228.1282755563070; Wed, 25 Aug 2010 09:59:23 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id d39sm2619802wam.4.2010.08.25.09.59.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Aug 2010 09:59:21 -0700 (PDT) Sender: Nicholas Weaver References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <84580414-1F3F-4B01-A41E-A0AB130D53A4@bbn.com> In-Reply-To: <84580414-1F3F-4B01-A41E-A0AB130D53A4@bbn.com> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <7B492A8E-4C44-4EB8-8B9E-7F7067309653@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 25 Aug 2010 09:59:19 -0700 To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Certs vs. hash-of-certs vs. keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 16:58:51 -0000 On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote: > Volume II: Certs vs. keys >=20 > A related discussion we should be having is whether we want to be = talking about certs or keys in the DNS. (Whether directly, e.g., as a = subjectPublicKeyInfo structure, or hashed.) It seems to me that working = with keys would be more flexible, since you wouldn't be bound to a = single cert. That is, you could present multiple certs without having = to have multiple RRs, and you could change your cert without updating = the DNS (e.g., to renew it). I don't see how this would be the case: you have N keys or N certs means = N records for the host. =20 And is there really a difference? A "CERT" is simply the key-format = desired by the application: SSL's CERTs are x509, but the "CERT" for SSH = is just the bare host key: this seems like a distinction without a = difference to me. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DBDA3A6AD6 for ; Wed, 25 Aug 2010 09:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dIzvmAaIUqT for ; Wed, 25 Aug 2010 09:49:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DCF2D3A6B29 for ; Wed, 25 Aug 2010 09:49:38 -0700 (PDT) Received: from [192.1.255.185] (port=51600 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoJAx-0004LD-FZ; Wed, 25 Aug 2010 12:50:11 -0400 Message-Id: <84580414-1F3F-4B01-A41E-A0AB130D53A4@bbn.com> From: "Richard L. Barnes" To: Paul Hoffman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Aug 2010 12:50:10 -0400 References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: [keyassure] Certs vs. hash-of-certs vs. keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 16:49:40 -0000 Volume I: Certs vs. hash-of-certs It's actually kind of a big reduction in triviality. The SSL libraries right now are set up so that users provide trust anchors in the form of certs instead of fingerprints. (At least, I'm not aware of any that do the latter.) If you require fingerprint matching in the validation, you have to start mucking around with TLS libraries, instead of just being able to make use of existing libraries. The one thing you could do to hack around this is do post-hoc checking: Accept the cert to establish the TLS connection, then validate it and terminate the connection if the validation fails. But in order to make that secure, you basically have to put the connection on hold while you do the validation, which is a little weird. And that in addition to the sort of philosophical point that it seems like the TLS negotiation should fail if you're not ultimately going to accept it. Volume II: Certs vs. keys A related discussion we should be having is whether we want to be talking about certs or keys in the DNS. (Whether directly, e.g., as a subjectPublicKeyInfo structure, or hashed.) It seems to me that working with keys would be more flexible, since you wouldn't be bound to a single cert. That is, you could present multiple certs without having to have multiple RRs, and you could change your cert without updating the DNS (e.g., to renew it). Using keys, though, causes the same implementation issues as above, whether they're represented as keys or fingerprints. So there's a trade-off here between implementation complexity and operational complexity. --Richard On Aug 25, 2010, at 12:01 PM, Paul Hoffman wrote: > At 9:23 PM -0400 8/24/10, Richard L. Barnes wrote: >> 3. I realize that it's slightly more efficient for the DNS to >> transmit fingerprints, but I still prefer to have the whole cert >> there because it allows for a really trivial implementation: >> > msg00209.html> > > Depending on the certificate, it is *much* more efficient to > transmit fingerprints. I don't think adding a single hash function > call to the comparison reduces the triviality by much. > > --Paul Hoffman, Director > --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F573A6B46 for ; Wed, 25 Aug 2010 09:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.752 X-Spam-Level: X-Spam-Status: No, score=-99.752 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2k9V6iWvv03 for ; Wed, 25 Aug 2010 09:21:15 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C42013A681F for ; Wed, 25 Aug 2010 09:21:14 -0700 (PDT) Received: from [75.101.18.87] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7PGB9jh025583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2010 09:11:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> Date: Wed, 25 Aug 2010 09:01:32 -0700 To: "Richard L. Barnes" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: [keyassure] Certs vs. hash-of-certs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 16:21:16 -0000 At 9:23 PM -0400 8/24/10, Richard L. Barnes wrote: >3. I realize that it's slightly more efficient for the DNS to transmit fingerprints, but I still prefer to have the whole cert there because it allows for a really trivial implementation: > Depending on the certificate, it is *much* more efficient to transmit fingerprints. I don't think adding a single hash function call to the comparison reduces the triviality by much. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042A13A6896 for ; Wed, 25 Aug 2010 09:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.458 X-Spam-Level: X-Spam-Status: No, score=-99.458 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mjOZN59vvUI for ; Wed, 25 Aug 2010 09:10:41 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 459183A69AA for ; Wed, 25 Aug 2010 09:10:40 -0700 (PDT) Received: from [75.101.18.87] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7PGB9jj025583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2010 09:11:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> Date: Wed, 25 Aug 2010 09:10:34 -0700 To: keyassure@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [keyassure] On eliminating ports X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 16:10:43 -0000 First off, one of the more common criticisms we got on the -00 was the complication of the ports, so this is not clear-cut. Having said that, I believe the *only* situation where specifying the ports in the TSLFP CERT request is valuable is when all the following are true: a) There are more than five or so servers on different ports on server.example.com b) Each server uses a different certificate c) The users always go to the tuple { dns=server.example.com && port=nnn } If (a) and (b) are true but (c) is not, for example if there are addional names such as www.example.com and imap.example.com for the various servers, there is no problem because the user will look up the individual name. If (a) and (c) are true but (b) is not, there is no problem because the user will get a useful response regardless of the port they go to. If (b) and (c) are true but (a) is not, then the client software needs compare the hash of the cert gotten in TLS against a small number of hashes. The only problem here is that the request for the TLSFP CERT RR is somewhat large. In what real-world use cases is this a problem? --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E69A3A6877 for ; Wed, 25 Aug 2010 00:41:25 -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_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knY+YCBihXqy for ; Wed, 25 Aug 2010 00:41:24 -0700 (PDT) Received: from mail.kirei.se (wagaya.kirei.se [91.206.174.10]) by core3.amsl.com (Postfix) with ESMTP id 437863A685A for ; Wed, 25 Aug 2010 00:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kirei.se; s=wagaya20060620; t=1282722115; bh=gOm+3dXMtkypd/taDcT9uL5hUQ+B5UGBsBJit409izU=; h=Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IEhHKLjalX3F7tg5POGUYWyr6CcbB5MU/P8COYPLHrhQ5TTt6i036znGY3iCIwGks 5rxKwuSpKtBQr2MgyVDYAaKdIfehlpGiiE1bjGqVsHN3W6vhimuJSQQ3Xn5ET2fvEA tm5TJZyuOfgblA2DVTRoSisLa7a3CqKJvYRDFaRM= Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Wed, 25 Aug 2010 09:41:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <1FE24211-79AA-41A7-9E7A-66288D93E4B0@kirei.se> <65B22D8C-96AA-4CA4-AFE1-F032256DBC99@kirei.se> To: Vladimir Jirasek X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 07:41:25 -0000 On 25 aug 2010, at 09.38, Vladimir Jirasek wrote: I also like to note that if we would do SRV records, the existance of a = SRV(_https._tcp.example.com) and a non-existance of a = SRV(_http.tcp.example.com) is a pretty good indicator that HTTPS is = required (aka strict transport security) by the service.=20 jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3573A685A for ; Wed, 25 Aug 2010 00:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL3WOPFxSDgG for ; Wed, 25 Aug 2010 00:38:20 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C4BAE3A67F7 for ; Wed, 25 Aug 2010 00:38:19 -0700 (PDT) Received: by fxm18 with SMTP id 18so155488fxm.31 for ; Wed, 25 Aug 2010 00:38:52 -0700 (PDT) Received: by 10.103.52.14 with SMTP id e14mr151979muk.74.1282721932182; Wed, 25 Aug 2010 00:38:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.102.169.18 with HTTP; Wed, 25 Aug 2010 00:38:32 -0700 (PDT) In-Reply-To: <65B22D8C-96AA-4CA4-AFE1-F032256DBC99@kirei.se> References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <1FE24211-79AA-41A7-9E7A-66288D93E4B0@kirei.se> <65B22D8C-96AA-4CA4-AFE1-F032256DBC99@kirei.se> From: Vladimir Jirasek Date: Wed, 25 Aug 2010 08:38:32 +0100 Message-ID: To: Jakob Schlyter Content-Type: multipart/alternative; boundary=001485f271cc1d0712048ea0f9c8 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 07:38:21 -0000 --001485f271cc1d0712048ea0f9c8 Content-Type: text/plain; charset=ISO-8859-1 I see. Should not that be more like: _*https*._tcp.example.com. IN CERT TLSFP 0 0 AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ== I see what you mean and it make sense. ----------------- Vladimir Jirasek www.jirasek.eu +447538790302 GoogleTalk: vladimir@jirasek.eu Read my blog: blog.jirasek.eu On 25 August 2010 08:36, Jakob Schlyter wrote: > On 25 aug 2010, at 09.01, Vladimir Jirasek wrote: > > > I do not understand what you mean with using SRV records and ports? yes > you can store port number in SRV records (that is why there are here in the > first place) but I do not see how this alone helps CERT records. Can you > elaborate by example please? > > e.g., > > _http._tcp.example.com. IN CERT TLSFP 0 0 > AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ== > > > jakob > > --001485f271cc1d0712048ea0f9c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see. Should not that be more like:

_https._tcp.example.com. IN CERT TLSFP 0 = 0 AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ=3D=3D

I see what yo= u mean and it make sense.

-----------------
Vladimir Jirasek
www.jirasek.eu=A0=A0 +447538790302
GoogleTalk: vladimir@jirasek.eu
Read my blog: blog.jirasek.eu



On 25 August 2010 08:36, Jakob Schlyter = <jakob@kirei.se&= gt; wrote:
On 25 aug 2010, at 09.01, Vladimir Jirasek wrote:

> I do not understand what you mean with using SRV records and ports? ye= s you can store port number in SRV records (that is why there are here in t= he first place) but I do not see how this alone helps CERT records. Can you= elaborate by example please?

e.g.,

_http._tcp.example.com= . IN CERT TLSFP 0 0 AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ=3D= =3D


=A0 =A0 =A0 =A0jakob


--001485f271cc1d0712048ea0f9c8-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB9C3A693D for ; Wed, 25 Aug 2010 00:36:18 -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_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD39KzWB2Oyq for ; Wed, 25 Aug 2010 00:36:17 -0700 (PDT) Received: from mail.kirei.se (wagaya.kirei.se [91.206.174.10]) by core3.amsl.com (Postfix) with ESMTP id 16FF53A6877 for ; Wed, 25 Aug 2010 00:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kirei.se; s=wagaya20060620; t=1282721803; bh=tYtBzBakOqVk4AXyDyk4d390WQa/vY1L+VnU2EztcF4=; h=Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aZD6QbqXsfwPU2d/EKdwFfrChvMvKissXCzMP7QF1Pln5kIqIXCXzEUc1N28r5EC6 Il467kF5vMfxogtM5iG07H/MNqmiDKN6hqq53tO0iaZONqOLyl3FoeTTwMzLcmSkp5 Y632znzEmTOT5gT3/hzLB3ptQVvxQHXhJF1gZCdc= Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Wed, 25 Aug 2010 09:36:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65B22D8C-96AA-4CA4-AFE1-F032256DBC99@kirei.se> References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <1FE24211-79AA-41A7-9E7A-66288D93E4B0@kirei.se> To: Vladimir Jirasek X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 07:36:18 -0000 On 25 aug 2010, at 09.01, Vladimir Jirasek wrote: > I do not understand what you mean with using SRV records and ports? = yes you can store port number in SRV records (that is why there are here = in the first place) but I do not see how this alone helps CERT records. = Can you elaborate by example please? e.g., _http._tcp.example.com. IN CERT TLSFP 0 0 = AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ=3D=3D jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1388A3A67F7 for ; Wed, 25 Aug 2010 00:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V92eO7xJFoH for ; Wed, 25 Aug 2010 00:01:47 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 96B723A687D for ; Wed, 25 Aug 2010 00:01:47 -0700 (PDT) Received: by fxm18 with SMTP id 18so143628fxm.31 for ; Wed, 25 Aug 2010 00:02:20 -0700 (PDT) Received: by 10.103.24.15 with SMTP id b15mr156376muj.39.1282719739180; Wed, 25 Aug 2010 00:02:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.102.169.18 with HTTP; Wed, 25 Aug 2010 00:01:59 -0700 (PDT) In-Reply-To: <1FE24211-79AA-41A7-9E7A-66288D93E4B0@kirei.se> References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> <1FE24211-79AA-41A7-9E7A-66288D93E4B0@kirei.se> From: Vladimir Jirasek Date: Wed, 25 Aug 2010 08:01:59 +0100 Message-ID: To: Jakob Schlyter , "Richard L. Barnes" , keyassure@ietf.org, Paul Hoffman Content-Type: multipart/alternative; boundary=0016e65a0fbc667630048ea0764a Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 07:01:49 -0000 --0016e65a0fbc667630048ea0764a Content-Type: text/plain; charset=ISO-8859-1 Hello, re point a) you are right, the SRV records are likely outside of the scope of this WG, I included it as an example of connecting it together. It is not widely deployed, pretty much as CERT RR records are not deployed. So this is an opportunity to push it more to wide implementation. re point b) I think limiting the DNS records to just a given name without the port is limiting in my view. One given name can be running diferent services using different certificates. I do not understand what you mean with using SRV records and ports? yes you can store port number in SRV records (that is why there are here in the first place) but I do not see how this alone helps CERT records. Can you elaborate by example please? Regards ----------------- Vladimir Jirasek www.jirasek.eu +447538790302 GoogleTalk: vladimir@jirasek.eu Read my blog: blog.jirasek.eu On 25 August 2010 07:53, Jakob Schlyter wrote: > There are two different issues here; > > a) The use of SRV to locate server X for name Y. This is not widely > deployed (yet), and I'm not sure it is within the scope of this non-WG to > address this lack of support. > > b) Support for per protocol certificates for name Y. In our draft we > suggest that we limit ourselves to one (equal) set of certificates for a > given name. If this limitation is critical, I suggest we look into SRV > naming for the CERT records instead of encoding protocol/port in the record > itself. This also has the benefit that existing CERT records can use the > same convention. > > > jakob > > --0016e65a0fbc667630048ea0764a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

re point a) you are right, the SRV records are likely outside= of the scope of this WG, I included it as an example of connecting it toge= ther. It is not widely deployed, pretty much as CERT RR records are not dep= loyed. So this is an opportunity to push it more to wide implementation. =A0
re point b) I think limiting the DNS records to just a given name wi= thout the port is limiting in my view. One given name can be running difere= nt services using different certificates.
I do not understand what you m= ean with using SRV records and ports? yes you can store port number in SRV = records (that is why there are here in the first place) but I do not see ho= w this alone helps CERT records. Can you elaborate by example please?

Regards

-----------------
Vladimir Jirasek
www.jirasek.eu=A0=A0 +447538790302
GoogleTalk: vladimir@jirasek.eu
Read my blog: blog.jirasek.eu



On 25 August 2010 07:53, Jakob Schlyter = <jakob@kirei.se&= gt; wrote:
There are two different issues here;

a) The use of SRV to locate server X for name Y. This is not widely deploye= d (yet), and I'm not sure it is within the scope of this non-WG to addr= ess this lack of support.

b) Support for per protocol certificates for name Y. In our draft we sugges= t that we limit ourselves to one (equal) set of certificates for a given na= me. =A0If this limitation is critical, I suggest we look into SRV naming fo= r the CERT records instead of encoding protocol/port in the record itself. = This also has the benefit that existing CERT records can use the same conve= ntion.


=A0 =A0 =A0 =A0jakob


--0016e65a0fbc667630048ea0764a-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FE03A6A7C for ; Tue, 24 Aug 2010 23:52:50 -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_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qoI-BMRszPC for ; Tue, 24 Aug 2010 23:52:49 -0700 (PDT) Received: from mail.kirei.se (wagaya.kirei.se [91.206.174.10]) by core3.amsl.com (Postfix) with ESMTP id D38593A6A96 for ; Tue, 24 Aug 2010 23:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kirei.se; s=wagaya20060620; t=1282719198; bh=ad9EBlUD0/RTIcAyRhUgeNjmGSi5uILhMAbu8QRfbIc=; h=Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VwB+Jil53P004BVzksW3FhUpT2hSBomOpzX5AbwNopTOWxVMrRqrBQIClt59qkHnj 2zZpU2ybFgQ2RPognuy+T5qy/IKuICEeAZv51bvN5QYQZa53Ug7YxcCfmfdNSmkv+0 4o6CeQOAY7lIUgBNoW89CInxSFN7hCi8jCoSvj74= Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Wed, 25 Aug 2010 08:53:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1FE24211-79AA-41A7-9E7A-66288D93E4B0@kirei.se> References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> To: Vladimir Jirasek X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 06:52:50 -0000 There are two different issues here; a) The use of SRV to locate server X for name Y. This is not widely = deployed (yet), and I'm not sure it is within the scope of this non-WG = to address this lack of support. b) Support for per protocol certificates for name Y. In our draft we = suggest that we limit ourselves to one (equal) set of certificates for a = given name. If this limitation is critical, I suggest we look into SRV = naming for the CERT records instead of encoding protocol/port in the = record itself. This also has the benefit that existing CERT records can = use the same convention. jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFD13A68DF for ; Tue, 24 Aug 2010 23:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFQKpxOVEhrV for ; Tue, 24 Aug 2010 23:33:31 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 018983A687D for ; Tue, 24 Aug 2010 23:33:30 -0700 (PDT) Received: by fxm18 with SMTP id 18so135682fxm.31 for ; Tue, 24 Aug 2010 23:34:03 -0700 (PDT) Received: by 10.103.192.20 with SMTP id u20mr156464mup.46.1282718043175; Tue, 24 Aug 2010 23:34:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.102.169.18 with HTTP; Tue, 24 Aug 2010 23:33:43 -0700 (PDT) In-Reply-To: References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> From: Vladimir Jirasek Date: Wed, 25 Aug 2010 07:33:43 +0100 Message-ID: To: Jakob Schlyter , "Richard L. Barnes" , keyassure@ietf.org, Paul Hoffman Content-Type: multipart/alternative; boundary=001636a7d85e4f7ce4048ea011f6 Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 06:33:34 -0000 --001636a7d85e4f7ce4048ea011f6 Content-Type: text/plain; charset=ISO-8859-1 Hello, I realised that the lack of information about the ports is more important that previously thought. I envisage this RFC to cover other TLS services than just HTTPs. These include POPs, SMTPS (including STARTTLS potentially), IMAPs, FTPs, etc. If that is the intention, and I think it should be, then we need to couple two DNS queries to get desired effect. To illustrate I show the example. Users want to access google IMAP server on imap.google.com over IMAPs: 1. the email client queries _imaps._tcp.imap.google.com SRV record and receives response that IMAPs service is on port 993 on server imap.google.com 2. it opens the TLS connection to imap.google.com on port 993 and receives the certificate(s) and extracts the certificate fingerprint 3. client queries CERT RR: imap.google.com CERT - same query as currently proposed the record in the DNS is stored as: imap.google.com. IN CERT TLSFP 0 0 ( AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ==:993 ) - note that I added port number after double colon to indicate that the cert is located on port 993 4. the response sent back to client is as per record above and the client extracts the certificate hash and port number and verifies it against the certificate it already has from step 2. This simple, in my view, change will allow for any service to be verified. I also think the existing proposal can be modified easily to modify the storage of the certificate has with the port number. Please note that it does not specify the protocol (tcp or udp). Finally, if this is coupled with SRV records to indicate ports and servers where _imap._tcp service is running (_imap._tcp.imap.google.com. IN SRV 0 5 993 imap.google.com.) the email client does not even need to be configured what port the service should be on, something users get wrong occasionally. Obviously the example above applies to HTTPs as well :) I hope this makes sense. ----------------- Vladimir Jirasek www.jirasek.eu +447538790302 GoogleTalk: vladimir@jirasek.eu Read my blog: blog.jirasek.eu On 25 August 2010 07:01, Jakob Schlyter wrote: > On 25 aug 2010, at 03.23, Richard L. Barnes wrote: > > > 1. It's not clear to me from your document what name I should query for > the CERT RRs. If I'm trying to authenticate www.example.com, do I look > under www.example.com, or something else? If it's the former, that could > be helpful for generalizing to the SRV case, and would help with the concern > about multiple services (to some extent). > > For now I think have to assume that you lookup the name that you are trying > to connect to, the owner of the A/AAAA record. > > In case of SRV; would you look up the name of the SRV record or the > destination? I'm not sure. For SMTP, I would look up the certificate of the > MX destination, not the MX domain. > > > 3. I realize that it's slightly more efficient for the DNS to transmit > fingerprints, but I still prefer to have the whole cert there because it > allows for a really trivial implementation: > > > > If you want to do whole certs, you can just use CERT PKIX certificate type > - it's already defined and ready to implement. However, CERTs tend to be on > the larger side - 1k+ - resulting in pretty large response sizes. > > > jakob > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --001636a7d85e4f7ce4048ea011f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I realised that the lack of information about the ports is mo= re important that previously thought. I envisage this RFC to cover other TL= S services than just HTTPs. These include POPs, SMTPS (including STARTTLS p= otentially), IMAPs, FTPs, etc.
If that is the intention, and I think it should be, then we need to couple = two DNS queries to get desired effect. To illustrate I show the example.
Users want to access google IMAP server on imap.google.com over IMAPs:

1. the email client queries _imaps._tcp.imap.google.com SRV record and receives respo= nse that IMAPs service is on port 993 on server imap.google.com
2. it opens the TLS connection to imap.google.com on port 993 and receives the certificate(s)= and extracts the certificate fingerprint
3. client queries CERT RR: imap.google.com CERT = - same query as currently proposed
the record in the DNS is stored as: 

imap.google.com. IN CERT TLSFP 0 0 ( AQGa+FZ=
d8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ=3D=3D:993 ) - note that I added por=
t number after double colon to indicate that the cert is located on port 99=
3
4. the response sent back to client is as per record above and the cl= ient extracts the certificate hash and port number and verifies it against = the certificate it already has from step 2.

This simple, in my view,= change will allow for any service to be verified. I also think the existin= g proposal can be modified easily to modify the storage of the certificate = has with the port number. Please note that it does not specify the protocol= (tcp or udp).

Finally, if this is coupled with SRV records to indicate ports and serv= ers where _imap._tcp service is running (_imap._tcp.imap.google.com. IN SRV 0 5 993 imap.google.com.) the e= mail client does not even need to be configured what port the service shoul= d be on, something users get wrong occasionally.

Obviously the example above applies to HTTPs as well :)

I hope t= his makes sense.
-----------------
Vladimir Jirasek
www.jirasek.eu=A0=A0 +447538790302
GoogleTalk: vladimir@jirasek.eu
Read my blog: blog.jirasek.eu



On 25 August 2010 07:01, Jakob Schlyter = <j= akob@kirei.se> wrote:
On 25 aug 2010, at 03.23, Richard L. Barnes wrote:

> 1. It's not clear to me from your document what name I should quer= y for the CERT RRs. =A0If I'm trying to authenticate www.example.com, do I look under www.example.com, or s= omething else? =A0If it's the former, that could be helpful for general= izing to the SRV case, and would help with the concern about multiple servi= ces (to some extent).

For now I think have to assume that you lookup the name that you are = trying to connect to, the owner of the A/AAAA record.

In case of SRV; would you look up the name of the SRV record or the destina= tion? I'm not sure. For SMTP, I would look up the certificate of the MX= destination, not the MX domain.

> 3. I realize that it's slightly more efficient for the DNS to tran= smit fingerprints, but I still prefer to have the whole cert there because = it allows for a really trivial implementation:
> <http://www.ietf.org/mail-archive/web/keyas= sure/current/msg00209.html>

If you want to do whole certs, you can just use CERT PKIX certificate= type - it's already defined and ready to implement. However, CERTs ten= d to be on the larger side - 1k+ - resulting in pretty large response sizes= .


=A0 =A0 =A0 =A0jakob

_______________________________________________
keyassure mailing list
keyassure@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/keyassure

--001636a7d85e4f7ce4048ea011f6-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C1D3A6805 for ; Tue, 24 Aug 2010 23:01:09 -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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2uNEb3EDd8e for ; Tue, 24 Aug 2010 23:01:08 -0700 (PDT) Received: from mail.kirei.se (wagaya.kirei.se [91.206.174.10]) by core3.amsl.com (Postfix) with ESMTP id 236823A6823 for ; Tue, 24 Aug 2010 23:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kirei.se; s=wagaya20060620; t=1282716097; bh=fVsZh3yQ4t46NgG5Z5loZv/qknXWI45XtffHewBfZJM=; h=Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=AG4+ptMwGE9XGdL9J56ryTJZ1yRtO6g8OVrY9zhqyEzY4ne+cAHNXMD3U4wP+8W43 uBq7ugT4f8kB6IfcZ0kBS/aZ6i4s2B28yC6Xt8rZo8evqabOrUUCii9jnCKs51noEo LwpTR7eab80SwyjsGTt2R0nwoNnLeT3qLETGbYxI= Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> Date: Wed, 25 Aug 2010 08:01:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 06:01:10 -0000 On 25 aug 2010, at 03.23, Richard L. Barnes wrote: > 1. It's not clear to me from your document what name I should query = for the CERT RRs. If I'm trying to authenticate www.example.com, do I = look under www.example.com, or something else? If it's the former, that = could be helpful for generalizing to the SRV case, and would help with = the concern about multiple services (to some extent). For now I think have to assume that you lookup the name that you are = trying to connect to, the owner of the A/AAAA record. In case of SRV; would you look up the name of the SRV record or the = destination? I'm not sure. For SMTP, I would look up the certificate of = the MX destination, not the MX domain. > 3. I realize that it's slightly more efficient for the DNS to transmit = fingerprints, but I still prefer to have the whole cert there because it = allows for a really trivial implementation: > If you want to do whole certs, you can just use CERT PKIX certificate = type - it's already defined and ready to implement. However, CERTs tend = to be on the larger side - 1k+ - resulting in pretty large response = sizes. jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677723A681E for ; Tue, 24 Aug 2010 19:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3Z2oLFlUtsQ for ; Tue, 24 Aug 2010 19:55:50 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 24AD23A680B for ; Tue, 24 Aug 2010 19:55:50 -0700 (PDT) Received: by iwn3 with SMTP id 3so179806iwn.31 for ; Tue, 24 Aug 2010 19:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ibzK+Gpz2Uccm8zz+xlgu7oplYHDFX/+xChhUSRSpxA=; b=C73394EBxn+rcESEZRnZWrcd6m9AwpArAXqcJexvFgxVMQcwPwPozx7zCnKpYr2N/l NUqGIncQivjFiy7jkn0a9X8FIDJ5vLnr86NRkGb7s+bxh2rzLlPAaOMOIycPm47K3mpx WdfE99oXDTjdbNCpfheWzqztUkreXvHpdcSCU= 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:content-transfer-encoding; b=iDE5cSCjrp0NgWEM9F94ENWFL6lu7j4JWl14gOXByt7PW2Do9ZxXHrStOVggbOgIxJ HuKyCkHvwtkqtlePDmaoya7/AWc1NmkPiuhmM9HyRMux/4GGMmXqMSHwAM2MtZiU2jnM Zc/UArm4qiqoytp8FS6Mhj74tByTnDek/nUQs= MIME-Version: 1.0 Received: by 10.231.157.212 with SMTP id c20mr9274604ibx.186.1282704981821; Tue, 24 Aug 2010 19:56:21 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Tue, 24 Aug 2010 19:56:21 -0700 (PDT) In-Reply-To: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> References: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> Date: Tue, 24 Aug 2010 22:56:21 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 02:55:51 -0000 On Tue, Aug 24, 2010 at 9:23 PM, Richard L. Barnes wrote: > Couple of comments: > > 1. It's not clear to me from your document what name I should query for t= he > CERT RRs. =A0If I'm trying to authenticate www.example.com, do I look und= er > www.example.com, or something else? =A0If it's the former, that could be > helpful for generalizing to the SRV case, and would help with the concern > about multiple services (to some extent). I don't think it works as written. The SSL connection is going to present a certificate. If the objective here is to work with TLS then write a spec that allows the certificate presented in TLS to = be validated. > 2. With respect to Vladimir's concern about multiple services under the s= ame > name, the risk with the approach in the document is that one service on a > host can masquerade as another, since the client doesn't know which CERT > goes with which service. =A0So if you have different services at differen= t > security levels, you're kind of screwed. =A0You can kind of work around t= he > problem by assigning different host names for the two services (pointing = to > the same host): > https://www1.website.org:443 > https://www2.website.org:4443 > > On the one hand, I'm tempted to say it's not a big deal; it's all in the > same host, so just manage your host properly. (If there are multiple host= s > behind the name, ) =A0On the other hand, if you weren't concerned about > service separation, why did you give them different certs in the first > place. =A0On balance, though, I think the above work-around is probably g= ood > enough. It looks to me like this is punting on the real problem in the design. You have the cert in hand when you want to get the assurance. So it is not impossible to do this right. > 3. I realize that it's slightly more efficient for the DNS to transmit > fingerprints, but I still prefer to have the whole cert there because it > allows for a really trivial implementation: > It does not help for SSL. But the point of using the CERT record is precisely to allow this flexibili= ty. Incidentally, if this project is going to be limited in scope to SSL then it should probably be discussed by the existing TLS working group. --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7BA3A6968 for ; Tue, 24 Aug 2010 18:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bctRor+SAMR for ; Tue, 24 Aug 2010 18:23:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id C25BF3A68A0 for ; Tue, 24 Aug 2010 18:23:25 -0700 (PDT) Received: from [128.89.253.166] (port=63286 helo=[192.168.1.43]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Oo4ib-000IT5-VO; Tue, 24 Aug 2010 21:23:58 -0400 Message-Id: <0A91F957-B817-4BE1-8301-C220844985E8@bbn.com> From: "Richard L. Barnes" To: Paul Hoffman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Aug 2010 21:23:56 -0400 References: X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 01:23:27 -0000 Couple of comments: 1. It's not clear to me from your document what name I should query for the CERT RRs. If I'm trying to authenticate www.example.com, do I look under www.example.com, or something else? If it's the former, that could be helpful for generalizing to the SRV case, and would help with the concern about multiple services (to some extent). 2. With respect to Vladimir's concern about multiple services under the same name, the risk with the approach in the document is that one service on a host can masquerade as another, since the client doesn't know which CERT goes with which service. So if you have different services at different security levels, you're kind of screwed. You can kind of work around the problem by assigning different host names for the two services (pointing to the same host): https://www1.website.org:443 https://www2.website.org:4443 On the one hand, I'm tempted to say it's not a big deal; it's all in the same host, so just manage your host properly. (If there are multiple hosts behind the name, ) On the other hand, if you weren't concerned about service separation, why did you give them different certs in the first place. On balance, though, I think the above work- around is probably good enough. 3. I realize that it's slightly more efficient for the DNS to transmit fingerprints, but I still prefer to have the whole cert there because it allows for a really trivial implementation: On Aug 24, 2010, at 6:32 PM, Paul Hoffman wrote: > We made some significant updates based on some of the traffic here, > the biggest being we now do hash-of-cert instead of hash-of-key and > we got rid of ports. > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Using Secure DNS to Associate Certificates with > Domain Names For TLS > Author(s) : P. Hoffman, et al. > Filename : draft-hoffman-keys-linkage-from-dns-01.txt > Pages : 8 > Date : 2010-08-24 > > TLS and DTLS uses certificates for authenticating the server. Users > want their applications to verify that the certificate provided by > the TLS server is in fact associated with the domain name they > expect. Instead of trusting a certificate authority to have made > this association correctly, the user might instead trust the > authoritative DNS server for the domain name to make that > association. This document describes how to use secure DNS to > associate the TLS server's certificate with the the intended domain > name. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-01.txt > > > The summary of changes is: > > Appendix B. Changes between -00 and -01 > > Change the association from being a hash of the key of a PKIX > certificate to being a hash of a certificate (PKIX or other). This, > of course, makes large changes throughout the document. > > Expanded the document to cover DTLS as well. > > Added a pointer to the keyassure mailing list. > > Removed the proposals for two alternate formats (the TLSFP Resource > Record and the TXT record encoding). Added a bit to Appendix A > about > this. > > Got rid of the specification for ports within a single domain name. > > Made the hash type one octet and used the DS registry instead of > defining our own. > > Added "Necessarily" chosen in the title of Appendix A to show that > we > might (continue to) change our minds after discussion. > > Added Simon Josefsson to the acknowledgements. > > > We hope this helps form the discussion here. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347CD3A694E for ; Tue, 24 Aug 2010 17:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.029 X-Spam-Level: X-Spam-Status: No, score=-99.029 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QI3IPpU2O0tT for ; Tue, 24 Aug 2010 17:09:39 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id F27313A6407 for ; Tue, 24 Aug 2010 17:09:38 -0700 (PDT) Received: from [75.101.18.87] (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 o7P0AAJc068403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2010 17:10:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <26860C09-3FC4-4348-B4F6-255004EBA5B3@jirasek.eu> References: <26860C09-3FC4-4348-B4F6-255004EBA5B3@jirasek.eu> Date: Tue, 24 Aug 2010 17:10:04 -0700 To: Vladimir Jirasek From: Paul Hoffman Content-Type: text/html; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 00:09:40 -0000 Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01
At 12:26 AM +0100 8/25/10, Vladimir Jirasek wrote:
Paul,

I have joined the list today, on kind advice from Jeff Hodges. I have read the new proposal and I like it with one comment:

The removal of port numbers means the protocol cannot be used to validate multiple certificates running on one hostname but different ports (i.e. https://www.website.org:443 for the first business application and https://www.website.org:4443 for the second business application).

Yes, it can. The DNS request can get back multiple CERT RRs.
In this case the DNS admin must list all certificates (hashes of them) in multiple DNS RR.

Exactly right.

 It is not specified in the draft what happens if multiple records are returned in the DNS responses, and potentially in random order as DNS servers may use round robin method.

A summary of the paragraphs in Section 3 is:

1 - Use DNSSEC, otherwise don't bother
2 - If you get zero TLSFP CERT RRs, do normal TLS processing
3 - If you get one or more TLSFP CERT RRs that have hash functions that you do not understand, ignore those RRs
4 - Try each TLSFP CERT RRs (the order doesn't matter); if none match the hash of the cert, die with "access_denied"

I see now that we never actually said "Try each usable TLSFP CERT RR against the hash of the end-entity cert from the server. If you find a match, stop with success; if you don't, die with "access_denied". We can add that to the -02.

There is not security threat in not having these port numbers there. However, I think it should be specified what the TLS client should do in such circumstances; such as receiving all DNS responses and going through them one by one until a returned hash matches TLS certificate hash.

Yep, we should have had that. Thanks for noticing this (somewhat glaring) error!

--Paul Hoffman, Director
--VPN Consortium
Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4443A6A6A for ; Tue, 24 Aug 2010 16:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hQnPsfoCDKH for ; Tue, 24 Aug 2010 16:26:00 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id ACD073A686D for ; Tue, 24 Aug 2010 16:25:59 -0700 (PDT) Received: by eyd10 with SMTP id 10so4167793eyd.31 for ; Tue, 24 Aug 2010 16:26:32 -0700 (PDT) Received: by 10.213.33.197 with SMTP id i5mr4872669ebd.44.1282692391853; Tue, 24 Aug 2010 16:26:31 -0700 (PDT) Received: from [10.0.1.9] (cpc1-heme11-2-0-cust435.9-1.cable.virginmedia.com [81.104.45.180]) by mx.google.com with ESMTPS id a48sm1022144eei.18.2010.08.24.16.26.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Aug 2010 16:26:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-9--557492179 From: Vladimir Jirasek In-Reply-To: Date: Wed, 25 Aug 2010 00:26:25 +0100 Message-Id: <26860C09-3FC4-4348-B4F6-255004EBA5B3@jirasek.eu> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] draft-hoffman-keys-linkage-from-dns-01 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 23:26:33 -0000 --Apple-Mail-9--557492179 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Paul, I have joined the list today, on kind advice from Jeff Hodges. I have = read the new proposal and I like it with one comment: The removal of port numbers means the protocol cannot be used to = validate multiple certificates running on one hostname but different = ports (i.e. https://www.website.org:443 for the first business = application and https://www.website.org:4443 for the second business = application). In this case the DNS admin must list all certificates = (hashes of them) in multiple DNS RR. It is not specified in the draft = what happens if multiple records are returned in the DNS responses, and = potentially in random order as DNS servers may use round robin method. There is not security threat in not having these port numbers there. = However, I think it should be specified what the TLS client should do in = such circumstances; such as receiving all DNS responses and going = through them one by one until a returned hash matches TLS certificate = hash. I hope this helps. Vladimir Jirasek mobile: +447538 790302, Fax: +441727375073 Email and Gtalk: vladimir@jirasek.eu website: www.jirasek.eu blog: blog.jirasek.eu On 24 Aug 2010, at 23:32, Paul Hoffman wrote: > We made some significant updates based on some of the traffic here, = the biggest being we now do hash-of-cert instead of hash-of-key and we = got rid of ports. >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Using Secure DNS to Associate Certificates = with Domain Names For TLS > Author(s) : P. Hoffman, et al. > Filename : draft-hoffman-keys-linkage-from-dns-01.txt > Pages : 8 > Date : 2010-08-24 >=20 > TLS and DTLS uses certificates for authenticating the server. Users > want their applications to verify that the certificate provided by > the TLS server is in fact associated with the domain name they > expect. Instead of trusting a certificate authority to have made > this association correctly, the user might instead trust the > authoritative DNS server for the domain name to make that > association. This document describes how to use secure DNS to > associate the TLS server's certificate with the the intended domain > name. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-01= .txt >=20 >=20 > The summary of changes is: >=20 > Appendix B. Changes between -00 and -01 >=20 > Change the association from being a hash of the key of a PKIX > certificate to being a hash of a certificate (PKIX or other). This, > of course, makes large changes throughout the document. >=20 > Expanded the document to cover DTLS as well. >=20 > Added a pointer to the keyassure mailing list. >=20 > Removed the proposals for two alternate formats (the TLSFP Resource > Record and the TXT record encoding). Added a bit to Appendix A = about > this. >=20 > Got rid of the specification for ports within a single domain name. >=20 > Made the hash type one octet and used the DS registry instead of > defining our own. >=20 > Added "Necessarily" chosen in the title of Appendix A to show that = we > might (continue to) change our minds after discussion. >=20 > Added Simon Josefsson to the acknowledgements. >=20 >=20 > We hope this helps form the discussion here. >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure --Apple-Mail-9--557492179 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://www.website.org:443 for = the first business application and https://www.website.org:4443 = for the second business application). In this case the DNS admin must = list all certificates (hashes of them) in multiple DNS RR. It is not = specified in the draft what happens if multiple records are returned in = the DNS responses, and potentially in random order as DNS servers may = use round robin method.

There is not security = threat in not having these port numbers there. However, I think it = should be specified what the TLS client should do in such circumstances; = such as receiving all DNS responses and going through them one by one = until a returned hash matches TLS certificate = hash.

I hope this helps.

Vladimir = Jirasek
mobile: +447538 790302, = Fax: +441727375073
Email and Gtalk: vladimir@jirasek.eu
website: www.jirasek.eu

=

On 24 Aug 2010, at 23:32, Paul Hoffman wrote:

We = made some significant updates based on some of the traffic here, the = biggest being we now do hash-of-cert instead of hash-of-key and we got = rid of ports.

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

Title =           : Using = Secure DNS to Associate Certificates with Domain Names For TLS
Author(s) =       : P. Hoffman, et al.
Filename =        : = draft-hoffman-keys-linkage-from-dns-01.txt
Pages =           : 8
Date =            : = 2010-08-24

TLS and DTLS uses certificates for authenticating the = server.  Users
want their applications to verify that the = certificate provided by
the TLS server is in fact associated with the = domain name they
expect.  Instead of trusting a certificate = authority to have made
this association correctly, the user might = instead trust the
authoritative DNS server for the domain name to = make that
association.  This document describes how to use = secure DNS to
associate the TLS server's certificate with the the = intended domain
name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoffman-keys-linka= ge-from-dns-01.txt


The summary of changes = is:

Appendix B.  Changes between -00 and -01

=   Change the association from being a hash of the key of a = PKIX
  certificate to being a hash of a certificate (PKIX = or other).  This,
  of course, makes large changes = throughout the document.

  Expanded the document to = cover DTLS as well.

  Added a pointer to the keyassure = mailing list.

  Removed the proposals for two = alternate formats (the TLSFP Resource
  Record and the TXT = record encoding).  Added a bit to Appendix A about
=   this.

  Got rid of the specification for = ports within a single domain name.

  Made the hash = type one octet and used the DS registry instead of
=   defining our own.

  Added "Necessarily" = chosen in the title of Appendix A to show that we
  might = (continue to) change our minds after discussion.

=   Added Simon Josefsson to the acknowledgements.


We = hope this helps form the discussion here.

--Paul Hoffman, = Director
--VPN = Consortium
_______________________________________________
keyassure= mailing list
keyassure@ietf.org
https://www.i= etf.org/mailman/listinfo/keyassure

<= /body>= --Apple-Mail-9--557492179-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B1C3A69D4 for ; Tue, 24 Aug 2010 15:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.312 X-Spam-Level: X-Spam-Status: No, score=-100.312 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbuPuxhS-vcl for ; Tue, 24 Aug 2010 15:31:49 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C05443A6873 for ; Tue, 24 Aug 2010 15:31:49 -0700 (PDT) Received: from [75.101.18.87] (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 o7OMWLtT064291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Aug 2010 15:32:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 24 Aug 2010 15:32:20 -0700 To: keyassure@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [keyassure] draft-hoffman-keys-linkage-from-dns-01 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 22:31:52 -0000 We made some significant updates based on some of the traffic here, the biggest being we now do hash-of-cert instead of hash-of-key and we got rid of ports. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using Secure DNS to Associate Certificates with Domain Names For TLS Author(s) : P. Hoffman, et al. Filename : draft-hoffman-keys-linkage-from-dns-01.txt Pages : 8 Date : 2010-08-24 TLS and DTLS uses certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. Instead of trusting a certificate authority to have made this association correctly, the user might instead trust the authoritative DNS server for the domain name to make that association. This document describes how to use secure DNS to associate the TLS server's certificate with the the intended domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-01.txt The summary of changes is: Appendix B. Changes between -00 and -01 Change the association from being a hash of the key of a PKIX certificate to being a hash of a certificate (PKIX or other). This, of course, makes large changes throughout the document. Expanded the document to cover DTLS as well. Added a pointer to the keyassure mailing list. Removed the proposals for two alternate formats (the TLSFP Resource Record and the TXT record encoding). Added a bit to Appendix A about this. Got rid of the specification for ports within a single domain name. Made the hash type one octet and used the DS registry instead of defining our own. Added "Necessarily" chosen in the title of Appendix A to show that we might (continue to) change our minds after discussion. Added Simon Josefsson to the acknowledgements. We hope this helps form the discussion here. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 361B13A6A72 for ; Tue, 24 Aug 2010 12:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FXvs3wdgkc4 for ; Tue, 24 Aug 2010 12:36:15 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 7940A3A6A65 for ; Tue, 24 Aug 2010 12:35:58 -0700 (PDT) Received: from dhcp-172-29-46-185.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 623FC2284997; Tue, 24 Aug 2010 15:34:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Tue, 24 Aug 2010 15:36:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1078) Cc: keyassure@ietf.org Subject: Re: [keyassure] Sample code X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 19:36:19 -0000 On Aug 23, 2010, at 4:04 PM, Richard L. Barnes wrote: > Speaking, as Phillip was, of the importance of people writing code, = here's a little bit of sample code that illustrates why it's handy to = have the full cert in the DNS. (Even though it is, I acknowledge, more = than one needs, and does raise issues with certificate expiry.) Namely, = you can reduce implementation of DNSSEC-assured TLS keying to around 10 = lines. Wow, that's kinda sexy... W >=20 > CAVEAT EMPTOR: I haven't tested this, but at least it compiles and = links against libunbound and openssl. >=20 > -----BEGIN----- > #include > #include >=20 > void keyassure(char *name, SSL_CTX *ctx) { > // Obtain the CERT record from DNS, secured with DNSSEC > struct ub_ctx *dns_ctx =3D ub_ctx_create(); > struct ub_result *result; > ub_resolve( > dns_ctx, name, > 37, // TYPE CERT > 1, // CLASS IN > &result > ); >=20 > // If we got a DNSSC-signed CERT record, add it to the SSL CA list > if (result->secure && result->havedata) { > // Read the X509 bytes into an OpenSSL X509 object > // Skip 5 bytes of type/tag/algorithm in the rrdata > unsigned char *cert_data =3D (unsigned char*) result->data[0] + = 5; > int cert_len =3D result->len[0] - 5; > X509* cert =3D d2i_X509(NULL, cert_data, cert_len); > =09 > // Mark the cert as a trusted CA cert > SSL_add_client_CA(ctx, cert); > } > } >=20 > int main(int argc, char **argv) { > if (argc < 2) return 1; > SSL_CTX *ctx =3D SSL_CTX_new(TLSv1_method()); > keyassure(argv[1], ctx); > // Finish setting up context and make SSL connection... > } > -----END----- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F60A3A689C for ; Tue, 24 Aug 2010 10:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tazWMTFrnSLS for ; Tue, 24 Aug 2010 10:37:35 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id C87E13A68BF for ; Tue, 24 Aug 2010 10:37:34 -0700 (PDT) Received: by pvg7 with SMTP id 7so3214109pvg.31 for ; Tue, 24 Aug 2010 10:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PZIxMEE1i4/c2kDz/3iNKmo2IiN7eD925cviOYuLGl4=; b=eD2VOgyQtRcQBrvWpmNv8dBwOp48o0MuFl3UMw/TxuGyN1f26Tx7JORm7ueNSAM8+s pOu27l0MoWhFbEiSo75boKEjeJG2jvpaCzzc5rKa7sxfyf/S4KSMCAgKeA5lrYYCeRp6 et9D7yMqApV7tL8nhx18YjGfBA+q8Hx1Z3ECc= 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:content-transfer-encoding; b=qVnhHmkMPWbXloqF/stI2Z3NQtonhOqIgzMbonas+w1cIgQk0WsWCaHoDe5Qes76Fm GfnuTmzYRI134SW6dA2l6MWgj2A935OqK+wOa+YvzOjGBKTdeveXit0Q480ld2xIHYfD 2hg7vFAnX2+ue5H6Ir0ZpqVWqulFNHYHHP3Bk= MIME-Version: 1.0 Received: by 10.114.123.4 with SMTP id v4mr8149632wac.0.1282671487561; Tue, 24 Aug 2010 10:38:07 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Tue, 24 Aug 2010 10:38:05 -0700 (PDT) In-Reply-To: References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <25DC9C15-669A-4ABD-A5B3-570C11FB5557@Princeton.EDU> <0894A13A-B6E3-4CD3-8482-AA1FD72E9090@kth.se> <3736A8F4-1A44-4967-AC3B-5F09F607B766@kth.se> <91754BBB-3475-4532-A7A1-0C56BC7545EE@kth.se> Date: Tue, 24 Aug 2010 13:38:05 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Schultze Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 17:37:38 -0000 OK, so it sounds as if we have rough agreement on the idea of using one record for policy and another (probably CERT) for keys and try not to mix the two. I was thinking that the CA flag is optional. If we are talking about self-signed certs, adding an extension is trivial and allows the use of DNSSEC assured certs without the use of a policy record (ESRV) I prefer to break down proposals so that one part can proceed independently of the other. There are some other considerations we might want to take into account with the interaction of certs and wildcards. If we want to establish a service for *.example.com, we need to be able to provide a wildcard binding for the cert as well. I had originally thought of using the cert extension to specify the prefix part and the domain stem. So if I have example.com, I could create a cert that had the extension: DNS-CERT _tag1 example.com So if the cert is presented when trying to create a connection to www.example.com, the client looks for _tag1._http._tcp.example.com and not _tag1._http._tcp.www.example.com This mechanism would only permit upward traversal on the chain so if the cert is for example.com it could not be used for www.fred.com This approach may or may not be desirable. The disadvantage is that the intermediate DNS zone is not necessarily trustworthy (we had this discussion at length in DKIM) and so there is a risk of having rules of the form 'only allow within scope of the SOA' which sound great until you find out how DNS really works. A better solution might be to simply state that if anyone wants to do wildcarding with this scheme then they MUST use an ESRV record and the scheme proposed earlier and use the domain specified in the redirect. Incidentally, there is also an interaction with SRV that I spent a couple of weeks looking at a while back. Basically my conclusion was that if you are using SRV then you want to pull your cert records from the domain specified in the SRV record, not the host name that you used for the start of your discovery process. The reason that is important is that we should be able to support records of the form: _pop._tcp.hallambaker.com ESRV "ptr=3Dgmail.com" or _pop._tcp.hallambaker.com SRV 1 1 143 pop.google.com I use google for my mail service. If I have DNSSEC and Google has DNSSEC, then I should be able to create a pointer in my DNS that means that my client securely discovers the Google POP service. And to go one stage further. We could create a new IANA registry for abstract services which would specify management of a class of protocol. So rather than put yet another 'identity' protocol on the table, we might specify an abstract protocol that would group together Kerberos, SAML, IIM, etc. and a relying party could find out what is supported in a single record. In this case it would mean that instead of _pop._tcp.hallambaker.com ESRV "ptr=3Dgmail.com" _imap._tcp.hallambaker.com ESRV "ptr=3Dgmail.com" _submit._tcp.hallambaker.com ESRV "ptr=3Dgmail.com" The same might be specified as _mail._as.hallambaker.com ESRV "ptr=3Dgmail.com" And at gmail we might have: _mail._as.gmail.com ESRV "protocol=3Dpop,imap,submit ssl=3Drequired auth=3Dsecure ssl=3Drequired discover=3DSRV" _pop._tcp.gmail.com SRV .... _pop._tcp.gmail.com SRV .... ... Making this all work smoothly is the key to making Web Services practical in my view. Which in turn is the reason why I am looking at this whole problem a bit differently. On Tue, Aug 24, 2010 at 1:00 PM, Stephen Schultze wrote= : > On Aug 24, 2010, at 12:51 PM, Love H=F6rnquist =C5strand wrote: >> >> I prefer just using the "ESRV" + prefix entry instead of "ESRV" + prefix >> entry + CA putting stuff in my cert for the simple reason its on less >> component to change. >> >> The only advantage for CA putting stuff in my cert is that you can skip >> the ESRV step for the reason additional cert validation, you still might >> want it for TLS=3DREQUIRED part. > > As I understand the proposal, CA putting stuff in the cert is optional. > =A0That is how I think it should be. > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26D23A6B8F for ; Tue, 24 Aug 2010 10:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.823 X-Spam-Level: X-Spam-Status: No, score=-3.823 tagged_above=-999 required=5 tests=[AWL=-1.824, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThXSfmicTVhH for ; Tue, 24 Aug 2010 10:00:05 -0700 (PDT) Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id AEB2D3A6B8C for ; Tue, 24 Aug 2010 10:00:05 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7OH0c9M016079 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 24 Aug 2010 13:00:38 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7OH0bpF026989 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 24 Aug 2010 13:00:38 -0400 (EDT) Message-Id: From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Aug 2010 13:00:37 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <25DC9C15-669A-4ABD-A5B3-570C11FB5557@Princeton.EDU> <0894A13A-B6E3-4CD3-8482-AA1FD72E9090@kth.se> <3736A8F4-1A44-4967-AC3B-5F09F607B766@kth.se> <91754BBB-3475-4532-A7A1-0C56BC7545EE@kth.se> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6083 signatures=637993 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008240103 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 17:00:06 -0000 On Aug 24, 2010, at 12:51 PM, Love H=F6rnquist =C5strand wrote: > I prefer just using the "ESRV" + prefix entry instead of "ESRV" + =20 > prefix entry + CA putting stuff in my cert for the simple reason its =20= > on less component to change. > > The only advantage for CA putting stuff in my cert is that you can =20 > skip the ESRV step for the reason additional cert validation, you =20 > still might want it for TLS=3DREQUIRED part. As I understand the proposal, CA putting stuff in the cert is =20 optional. That is how I think it should be. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B27A3A6358 for ; Tue, 24 Aug 2010 09:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.64 X-Spam-Level: X-Spam-Status: No, score=-5.64 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LPnVf5+4FUq for ; Tue, 24 Aug 2010 09:51:34 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 7289E3A657C for ; Tue, 24 Aug 2010 09:51:33 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 37FDD15588C; Tue, 24 Aug 2010 18:51:35 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id WAbLpDxrPxjA; Tue, 24 Aug 2010 18:51:30 +0200 (CEST) X-KTH-Auth: lha [2620:0:1b00:1f08:8451:899f:2f0d:32c7] X-KTH-mail-from: lha@kth.se Received: from [IPv6:2620::1b00:1f08:8451:899f:2f0d:32c7] (unknown [IPv6:2620:0:1b00:1f08:8451:899f:2f0d:32c7]) by smtp-1.sys.kth.se (Postfix) with ESMTP id A96AB1563C2; Tue, 24 Aug 2010 18:51:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1162) Content-Type: multipart/signed; boundary=Apple-Mail-536--581202218; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: Date: Tue, 24 Aug 2010 09:51:15 -0700 Message-Id: References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <25DC9C15-669A-4ABD-A5B3-570C11FB5557@Princeton.EDU> <0894A13A-B6E3-4CD3-8482-AA1FD72E9090@kth.se> <3736A8F4-1A44-4967-AC3B-5F09F607B766@kth.se> <91754BBB-3475-4532-A7A1-0C56BC7545EE@kth.se> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1162) Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 16:51:35 -0000 --Apple-Mail-536--581202218 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I wasn't proposing putting the hash in the "ESRV" RR, just a signal that = the .original-entry exists (prefix entry). Using the prefix entry is good since it support multiple certs for one = hostname (load balancing) and migration to new certificates. All this = while not requiring users to pull down all RR of you would store the = cert-hashes in the data part of the RR. I prefer just using the "ESRV" + prefix entry instead of "ESRV" + prefix = entry + CA putting stuff in my cert for the simple reason its on less = component to change. The only advantage for CA putting stuff in my cert is that you can skip = the ESRV step for the reason additional cert validation, you still might = want it for TLS=3DREQUIRED part. Love 24 aug 2010 kl. 08:41 skrev Phillip Hallam-Baker: > If at all possible I would like to keep the policy record and the key > record separate for the purposes of discussion. Not everyone is going > to agree on the value of policy as it is a new capability. It is much > easier to get people to agree on re-solving an already solved problem > than a new one. Even though there is considerably less advantage to > doing so. >=20 > I agree that you can put the key hash in the policy record. But as I > show later in this post, that creates management issues at renewal > time because DNS records are cached. >=20 >=20 > How about this for a cert discovery mechanism? >=20 > Use of DNSSEC key assurance may be signaled using: >=20 > * An ESRV record > * An X.509v3 extension DNS-CERT > * A TLS extension >=20 > All three are possible design approaches. I prefer the first two as > they only affect parts of the system that we know we have to affect > anyway for the system to work (DNS, cert generation). TLS extensions > mean we have to upgrade the Web server before the system is useful. >=20 > Different CERT records may be distinguished according to a prefix = specified by: >=20 > * The prefix parameter of the X.509v3 extension DNS-CERT > * A fingerprint of the certificate generated using the hash algorithm > specified in the cert >=20 > In addition we need to have a mechanism for specifying that the use of > a cert is authorized with a particular protocol. At the moment there > is a port based proposal on the table and my proposal to use SRV > prefixes. >=20 > I much prefer the SRV prefix approach as I don't consider the port > assignments to be a scalable approach. We are going to have far more > than 65,535 protocols used on the Internet. And we already have > protocols that use multiple port numbers (X.11, FTP, VOIP) and HTTP is > designed to run on any port. >=20 >=20 > In the very simplest case, one host, one service, one cert we could in > theory express all the required information in a single record: >=20 > _imap._tcp.example.com ESRV "SSL=3DREQUIRED > CERT=3DSHA256:fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19=AC= > f0d2ce9d" >=20 > However, consider the logistical problems that occur when you need to > roll over the cert. The ESRV record will cache and so there is no > guarantee that a relying party is going to have the right record to > validate the cert presented. >=20 > Assuming that the cert has no 'DNS CERT" extension, the RR is going to > be something like: >=20 > _imap._tcp.example.com ESRV "SSL=3DREQUIRED ASSURANCE=3DDNS" >=20 > _fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19=AC > f0d2ce9d._imap._tcp.example.com CERT 9 15 > 83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19=AC > f0d2ce9d >=20 > If the cert does have the extension the RR would be something like >=20 > _imap._tcp.example.com ESRV "SSL=3DREQUIRED" >=20 > _eru32wir3._imap._tcp.example.com CERT 9 15 > 83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19=AC > f0d2ce9d >=20 >=20 > It would really not take any great effort to write a little tool that > would generate both the zone file specification and either the > certificate itself or CSR for submission to a CA. So the relative > opacity of these designations should not be a major concern. >=20 >=20 > On Tue, Aug 24, 2010 at 1:26 AM, Love H=F6rnquist =C5strand = wrote: >>=20 >> 23 aug 2010 kl. 22:10 skrev Phillip Hallam-Baker: >>=20 >>> Hmm, I didn't put that in the ESRV I presented. >>=20 >> I'm putting it there. >>=20 >>> It is certainly a possible design choice, the ESRV could have a flag >>> to say 'DNSSEC validation', but that would tie the key discovery to = my >>> ESRV mechanism. Which seems like tying something relatively >>> straightforward to something that I think has to be tailored to >>> specific protocols... >>=20 >> I don't think it tailor more then "use_tls" (or what you now called = it in ESRV). >>=20 >> Putting it the digest in DNS make the chain clearer in in the case of = self-signed certificates. >>=20 >> Love >>=20 >>=20 >>>=20 >>> I did propose a version last week where I put the certhash in the = ESRV >>> record. But that was when I was trying to make everything work with = a >>> single record and calling it something else... >>>=20 >>>=20 >>> On Tue, Aug 24, 2010 at 12:33 AM, Love H=F6rnquist =C5strand = wrote: >>>> It said so in your newly proposed ESRV RR. >>>>=20 >>>> Love >>>>=20 >>>>=20 >>>> 23 aug 2010 kl. 21:23 skrev Phillip Hallam-Baker: >>>>=20 >>>>> How do we know that the zone contains keys or certs at all? >>>>>=20 >>>>> That would seem rather an odd assumption when no SSL certs are >>>>> anchored in DNS at the moment. >>>>>=20 >>>>> Knowing that the site has DNSSEC does not tell apps to look there = for keys. >>>>>=20 >>>>>=20 >>>>> On Mon, Aug 23, 2010 at 11:58 PM, Love H=F6rnquist =C5strand = wrote: >>>>>>=20 >>>>>> 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker: >>>>>>=20 >>>>>> 5) Server presents certificate >>>>>>=20 >>>>>> Parse the certificate and find a DNS-CERT extension with prefix = _36fe829C >>>>>>=20 >>>>>> 6) Pull the DNS record to verify the certificate: >>>>>>=20 >>>>>> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y=3D=3D >>>>>> _36fe829C.host2.example.com CERT 1 8 = http://ca.example.com/36fe829C >>>>>> >>>>>>=20 >>>>>> Since we know that the site uses DNSSEC, just don't bother = checking for >>>>>> DNS-CERT extension and instead lookup >>>>>> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR. >>>>>> Love >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Website: http://hallambaker.com/ >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Website: http://hallambaker.com/ >>=20 >>=20 >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ --Apple-Mail-536--581202218 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQXzoqZKwXOvvxymIt KZOH2DANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDQwMTAwMDAwMFoXDTExMDQwMTIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxHzAdBgNVBAMUFkxvdmUgSPZy bnF1aXN0IMVzdHJhbmQxGTAXBgkqhkiG9w0BCQEWCmxoYUBrdGguc2UwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDExzsEl8kHec1Flo6WDOR55uZ9e526lJpegh+pnb7kUoiMc3+L+oTM HbAQs4hOjUV1+kwPsdnBFolLJ6CR5lkwyZBHjzdbHMXnxh2czeIDjaD1lWxnEPTPefGZ0LEUgbix pThFfdW6wA9z43J/1VsZeQU8ZEY50ZHSkhjM+1PFdgjL5RJv2j7sFgHVr7P2mvEFNTy+PCKW/1Gj agjSehjXvFCqs8O9Was/dEdQ8pyT216VBPi+S77qcbGYAH6yqQ0XqiF0ogBZE8jKnkUDhFZz60gC QqlClW6i7iczbalEjnvEx3z+tsUzIK2UGrwqv0BmCg0qz7T1RZgbTowy0D/BAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAF01Bxe7vzqE /pJ4hZ30dqxJDSjHVOSmKdAkHg/i0uKLbIs7C+RYDlOptqlrmXwE40cTjFk26XVimzYayfHev/mA lgqxPlQC28zhQTHi1VtwVUXwslphpGRJk/WK8esXu61gGgjEErcGtNB7G4KfymM3yQgIudUM4cZb Z+5Et5fzLd9WLHIqd5vb2IbC4Q/dg00lmIWmikQtjt9mi1EaUUIAiySzjI5e6Akq8uyeOw+7ccPg WZOPPfif8D0z0WDXpSwCyTo9SG/f1gvwPkuxfJ4pilIBVBPkS2zAb7a5ZM1xXdLIjbboFCLCzJhk VsK40ZdKTdMvp9t/M1O1D/b7U+MxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fYMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNDE2 NTExNlowIwYJKoZIhvcNAQkEMRYEFBN5c3YJYxUrCJFsetjBNQ9FNmWXMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEF86KmSsFzr78cpiLSmTh9gwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fY MA0GCSqGSIb3DQEBAQUABIIBACOvJ4zj/IdT7bqmZXoG4RaT06KwULuvnqVOPjeSg1Bqf368B3z1 SbUDNmTsibmvP+5NTBf3QazvQCbVXIdttBvK1pnkiuSgp+J43q+CXggPVNPV8ed7/f2UVAzLqbPJ CI0hG4lfq2Nj+Sv0xsvOmxy4iqaanUttucoLpaKhvEqFmw0rq3XP2OBvipGFDW17z+Iq5Krq/o6p LiyyTDJw76u+06jF+QZaT/Wv1CjK7ANgQej6lqArYP/X2AIM6vsBzpDcvB5M5O8JMgWw7RWvprft RYOmpcbSUmQQzUeusG30W0WBJyJQXqJJHNwWD23wYH0HWwvyoMAmp1vjz+JfKNQAAAAAAAA= --Apple-Mail-536--581202218-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5CEE3A6A43 for ; Tue, 24 Aug 2010 09:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.915 X-Spam-Level: X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UhBq5rRyguX for ; Tue, 24 Aug 2010 09:00:18 -0700 (PDT) Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id 6D0893A6B79 for ; Tue, 24 Aug 2010 09:00:17 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id o7OG0n8A013509 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 24 Aug 2010 12:00:50 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7OG0npF000076 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 24 Aug 2010 12:00:49 -0400 (EDT) Message-Id: From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Aug 2010 12:00:49 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <25DC9C15-669A-4ABD-A5B3-570C11FB5557@Princeton.EDU> <0894A13A-B6E3-4CD3-8482-AA1FD72E9090@kth.se> <3736A8F4-1A44-4967-AC3B-5F09F607B766@kth.se> <91754BBB-3475-4532-A7A1-0C56BC7545EE@kth.se> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6083 signatures=637993 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008240094 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 16:00:20 -0000 I basically agree. I would rephrase the first option ("An ESRV record") as "an RR" just =20 because we haven't settled on exactly how it is represented yet. It would be nice if that RR supported: - DNS wildcards (does ESRV?) - the ability to query for it before receiving and parsing the cert, =20 ie simultaneously with the initial A record query you are probably =20 already making If we use a prefix, why have two standards for the prefix? Why not =20 just always do it with the fingerprint of the cert/key? Other than =20 the X.509v3 extension DNS-CERT version being prettier for a human to =20 read, I'm not sure what the benefit is. For rollover, the logical solution seems to be to allow multiple certs/=20= RR's. This addresses other situations in which there are good reasons =20= to have more than one cert per service. On Aug 24, 2010, at 11:41 AM, Phillip Hallam-Baker wrote: > If at all possible I would like to keep the policy record and the key > record separate for the purposes of discussion. Not everyone is going > to agree on the value of policy as it is a new capability. It is much > easier to get people to agree on re-solving an already solved problem > than a new one. Even though there is considerably less advantage to > doing so. > > I agree that you can put the key hash in the policy record. But as I > show later in this post, that creates management issues at renewal > time because DNS records are cached. > > > How about this for a cert discovery mechanism? > > Use of DNSSEC key assurance may be signaled using: > > * An ESRV record > * An X.509v3 extension DNS-CERT > * A TLS extension > > All three are possible design approaches. I prefer the first two as > they only affect parts of the system that we know we have to affect > anyway for the system to work (DNS, cert generation). TLS extensions > mean we have to upgrade the Web server before the system is useful. > > Different CERT records may be distinguished according to a prefix =20 > specified by: > > * The prefix parameter of the X.509v3 extension DNS-CERT > * A fingerprint of the certificate generated using the hash algorithm > specified in the cert > > In addition we need to have a mechanism for specifying that the use of > a cert is authorized with a particular protocol. At the moment there > is a port based proposal on the table and my proposal to use SRV > prefixes. > > I much prefer the SRV prefix approach as I don't consider the port > assignments to be a scalable approach. We are going to have far more > than 65,535 protocols used on the Internet. And we already have > protocols that use multiple port numbers (X.11, FTP, VOIP) and HTTP is > designed to run on any port. > > > In the very simplest case, one host, one service, one cert we could in > theory express all the required information in a single record: > > _imap._tcp.example.com ESRV "SSL=3DREQUIRED > CERT=3DSHA256:fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19=AC= > f0d2ce9d" > > However, consider the logistical problems that occur when you need to > roll over the cert. The ESRV record will cache and so there is no > guarantee that a relying party is going to have the right record to > validate the cert presented. > > Assuming that the cert has no 'DNS CERT" extension, the RR is going to > be something like: > > _imap._tcp.example.com ESRV "SSL=3DREQUIRED ASSURANCE=3DDNS" > > _fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19=AC > f0d2ce9d._imap._tcp.example.com CERT 9 15 > 83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19=AC > f0d2ce9d > > If the cert does have the extension the RR would be something like > > _imap._tcp.example.com ESRV "SSL=3DREQUIRED" > > _eru32wir3._imap._tcp.example.com CERT 9 15 > 83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19=AC > f0d2ce9d > > > It would really not take any great effort to write a little tool that > would generate both the zone file specification and either the > certificate itself or CSR for submission to a CA. So the relative > opacity of these designations should not be a major concern. > > > On Tue, Aug 24, 2010 at 1:26 AM, Love H=F6rnquist =C5strand = =20 > wrote: >> >> 23 aug 2010 kl. 22:10 skrev Phillip Hallam-Baker: >> >>> Hmm, I didn't put that in the ESRV I presented. >> >> I'm putting it there. >> >>> It is certainly a possible design choice, the ESRV could have a flag >>> to say 'DNSSEC validation', but that would tie the key discovery =20 >>> to my >>> ESRV mechanism. Which seems like tying something relatively >>> straightforward to something that I think has to be tailored to >>> specific protocols... >> >> I don't think it tailor more then "use_tls" (or what you now called =20= >> it in ESRV). >> >> Putting it the digest in DNS make the chain clearer in in the case =20= >> of self-signed certificates. >> >> Love >> >> >>> >>> I did propose a version last week where I put the certhash in the =20= >>> ESRV >>> record. But that was when I was trying to make everything work =20 >>> with a >>> single record and calling it something else... >>> >>> >>> On Tue, Aug 24, 2010 at 12:33 AM, Love H=F6rnquist =C5strand =20 >>> wrote: >>>> It said so in your newly proposed ESRV RR. >>>> >>>> Love >>>> >>>> >>>> 23 aug 2010 kl. 21:23 skrev Phillip Hallam-Baker: >>>> >>>>> How do we know that the zone contains keys or certs at all? >>>>> >>>>> That would seem rather an odd assumption when no SSL certs are >>>>> anchored in DNS at the moment. >>>>> >>>>> Knowing that the site has DNSSEC does not tell apps to look =20 >>>>> there for keys. >>>>> >>>>> >>>>> On Mon, Aug 23, 2010 at 11:58 PM, Love H=F6rnquist =C5strand = >>>> > wrote: >>>>>> >>>>>> 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker: >>>>>> >>>>>> 5) Server presents certificate >>>>>> >>>>>> Parse the certificate and find a DNS-CERT extension with prefix =20= >>>>>> _36fe829C >>>>>> >>>>>> 6) Pull the DNS record to verify the certificate: >>>>>> >>>>>> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y=3D=3D >>>>>> _36fe829C.host2.example.com CERT 1 8 = http://ca.example.com/36fe829C >>>>>> >>>>>> >>>>>> Since we know that the site uses DNSSEC, just don't bother =20 >>>>>> checking for >>>>>> DNS-CERT extension and instead lookup >>>>>> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR. >>>>>> Love >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Website: http://hallambaker.com/ >>>> >>>> >>> >>> >>> >>> -- >>> Website: http://hallambaker.com/ >> >> > > > > --=20 > Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8C43A6B78 for ; Tue, 24 Aug 2010 08:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvTTcO1mz0-f for ; Tue, 24 Aug 2010 08:41:23 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 62E043A6A35 for ; Tue, 24 Aug 2010 08:41:23 -0700 (PDT) Received: by yxk8 with SMTP id 8so3064475yxk.31 for ; Tue, 24 Aug 2010 08:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A5+CangphX+B/t3dywpPe8ra/pi8bXFUQ6XwZ5vD/x4=; b=FsqS87bbZInaiy1HOMe5e6pGnmFm+pMesALRsubEAxBkrusxjE+OF3ub0DndZx3ptA EFs3rlQndQVMcBZZufaaa4xIBhrqodRzZ+UBcwJm7HFhMKCCQFt9feNUP3xhyxbpXMrk OYZevWQWZ7sJBdjguVfoqUSXr1l0Dj/KZ9VXM= 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:content-transfer-encoding; b=ht4qx3+I6JRV8qekouq6yLvyMbBrYMZZROfn0CbTIwouFwjtGnU0JxQhLJ3LGwz046 lucHYkLbkCnvysctdJ+1YWgkM32VlHnv2nQuVu7Dv2KwJpQsOVtP4oUxvQsLV/toFg+K hxO7u98iIcHAeu2vitucDC43lBoC3w5l7bs4E= MIME-Version: 1.0 Received: by 10.90.53.7 with SMTP id b7mr4791350aga.46.1282664516012; Tue, 24 Aug 2010 08:41:56 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Tue, 24 Aug 2010 08:41:38 -0700 (PDT) In-Reply-To: <91754BBB-3475-4532-A7A1-0C56BC7545EE@kth.se> References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <25DC9C15-669A-4ABD-A5B3-570C11FB5557@Princeton.EDU> <0894A13A-B6E3-4CD3-8482-AA1FD72E9090@kth.se> <3736A8F4-1A44-4967-AC3B-5F09F607B766@kth.se> <91754BBB-3475-4532-A7A1-0C56BC7545EE@kth.se> Date: Tue, 24 Aug 2010 11:41:38 -0400 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 15:41:25 -0000 If at all possible I would like to keep the policy record and the key record separate for the purposes of discussion. Not everyone is going to agree on the value of policy as it is a new capability. It is much easier to get people to agree on re-solving an already solved problem than a new one. Even though there is considerably less advantage to doing so. I agree that you can put the key hash in the policy record. But as I show later in this post, that creates management issues at renewal time because DNS records are cached. How about this for a cert discovery mechanism? Use of DNSSEC key assurance may be signaled using: * An ESRV record * An X.509v3 extension DNS-CERT * A TLS extension All three are possible design approaches. I prefer the first two as they only affect parts of the system that we know we have to affect anyway for the system to work (DNS, cert generation). TLS extensions mean we have to upgrade the Web server before the system is useful. Different CERT records may be distinguished according to a prefix specified= by: * The prefix parameter of the X.509v3 extension DNS-CERT * A fingerprint of the certificate generated using the hash algorithm specified in the cert In addition we need to have a mechanism for specifying that the use of a cert is authorized with a particular protocol. At the moment there is a port based proposal on the table and my proposal to use SRV prefixes. I much prefer the SRV prefix approach as I don't consider the port assignments to be a scalable approach. We are going to have far more than 65,535 protocols used on the Internet. And we already have protocols that use multiple port numbers (X.11, FTP, VOIP) and HTTP is designed to run on any port. In the very simplest case, one host, one service, one cert we could in theory express all the required information in a single record: _imap._tcp.example.com ESRV "SSL=3DREQUIRED CERT=3DSHA256:fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19=AC f0d2ce9d" However, consider the logistical problems that occur when you need to roll over the cert. The ESRV record will cache and so there is no guarantee that a relying party is going to have the right record to validate the cert presented. Assuming that the cert has no 'DNS CERT" extension, the RR is going to be something like: _imap._tcp.example.com ESRV "SSL=3DREQUIRED ASSURANCE=3DDNS" _fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19=AC f0d2ce9d._imap._tcp.example.com CERT 9 15 83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19=AC f0d2ce9d If the cert does have the extension the RR would be something like _imap._tcp.example.com ESRV "SSL=3DREQUIRED" _eru32wir3._imap._tcp.example.com CERT 9 15 83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19=AC f0d2ce9d It would really not take any great effort to write a little tool that would generate both the zone file specification and either the certificate itself or CSR for submission to a CA. So the relative opacity of these designations should not be a major concern. On Tue, Aug 24, 2010 at 1:26 AM, Love H=F6rnquist =C5strand wr= ote: > > 23 aug 2010 kl. 22:10 skrev Phillip Hallam-Baker: > >> Hmm, I didn't put that in the ESRV I presented. > > I'm putting it there. > >> It is certainly a possible design choice, the ESRV could have a flag >> to say 'DNSSEC validation', but that would tie the key discovery to my >> ESRV mechanism. Which seems like tying something relatively >> straightforward to something that I think has to be tailored to >> specific protocols... > > I don't think it tailor more then "use_tls" (or what you now called it in= ESRV). > > Putting it the digest in DNS make the chain clearer in in the case of sel= f-signed certificates. > > Love > > >> >> I did propose a version last week where I put the certhash in the ESRV >> record. But that was when I was trying to make everything work with a >> single record and calling it something else... >> >> >> On Tue, Aug 24, 2010 at 12:33 AM, Love H=F6rnquist =C5strand wrote: >>> It said so in your newly proposed ESRV RR. >>> >>> Love >>> >>> >>> 23 aug 2010 kl. 21:23 skrev Phillip Hallam-Baker: >>> >>>> How do we know that the zone contains keys or certs at all? >>>> >>>> That would seem rather an odd assumption when no SSL certs are >>>> anchored in DNS at the moment. >>>> >>>> Knowing that the site has DNSSEC does not tell apps to look there for = keys. >>>> >>>> >>>> On Mon, Aug 23, 2010 at 11:58 PM, Love H=F6rnquist =C5strand wrote: >>>>> >>>>> 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker: >>>>> >>>>> 5) =A0Server presents certificate >>>>> >>>>> Parse the certificate and find a DNS-CERT extension with prefix _36fe= 829C >>>>> >>>>> 6) Pull the DNS record to verify the certificate: >>>>> >>>>> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y=3D=3D >>>>> _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C >>>>> >>>>> >>>>> Since we know that the site uses DNSSEC, just don't bother checking f= or >>>>> DNS-CERT extension and instead lookup >>>>> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR. >>>>> Love >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Website: http://hallambaker.com/ >>> >>> >> >> >> >> -- >> Website: http://hallambaker.com/ > > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E282A3A6823 for ; Mon, 23 Aug 2010 22:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paEJx9-EGySs for ; Mon, 23 Aug 2010 22:26:31 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 98FEC3A684B for ; Mon, 23 Aug 2010 22:26:29 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 5B46F14DCA1; Tue, 24 Aug 2010 07:26:32 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id FxQTsPl8tJ0G; Tue, 24 Aug 2010 07:26:31 +0200 (CEST) X-KTH-Auth: lha [71.158.241.78] X-KTH-mail-from: lha@kth.se Received: from [192.168.1.101] (adsl-71-158-241-78.dsl.pltn13.sbcglobal.net [71.158.241.78]) by smtp-2.sys.kth.se (Postfix) with ESMTP id A9A9C14F102; Tue, 24 Aug 2010 07:26:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1162) Content-Type: multipart/signed; boundary=Apple-Mail-465--622297800; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: Date: Mon, 23 Aug 2010 22:26:20 -0700 Message-Id: <91754BBB-3475-4532-A7A1-0C56BC7545EE@kth.se> References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <25DC9C15-669A-4ABD-A5B3-570C11FB5557@Princeton.EDU> <0894A13A-B6E3-4CD3-8482-AA1FD72E9090@kth.se> <3736A8F4-1A44-4967-AC3B-5F09F607B766@kth.se> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1162) Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 05:26:37 -0000 --Apple-Mail-465--622297800 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 23 aug 2010 kl. 22:10 skrev Phillip Hallam-Baker: > Hmm, I didn't put that in the ESRV I presented. I'm putting it there. > It is certainly a possible design choice, the ESRV could have a flag > to say 'DNSSEC validation', but that would tie the key discovery to my > ESRV mechanism. Which seems like tying something relatively > straightforward to something that I think has to be tailored to > specific protocols... I don't think it tailor more then "use_tls" (or what you now called it = in ESRV). Putting it the digest in DNS make the chain clearer in in the case of = self-signed certificates. Love >=20 > I did propose a version last week where I put the certhash in the ESRV > record. But that was when I was trying to make everything work with a > single record and calling it something else... >=20 >=20 > On Tue, Aug 24, 2010 at 12:33 AM, Love H=F6rnquist =C5strand = wrote: >> It said so in your newly proposed ESRV RR. >>=20 >> Love >>=20 >>=20 >> 23 aug 2010 kl. 21:23 skrev Phillip Hallam-Baker: >>=20 >>> How do we know that the zone contains keys or certs at all? >>>=20 >>> That would seem rather an odd assumption when no SSL certs are >>> anchored in DNS at the moment. >>>=20 >>> Knowing that the site has DNSSEC does not tell apps to look there = for keys. >>>=20 >>>=20 >>> On Mon, Aug 23, 2010 at 11:58 PM, Love H=F6rnquist =C5strand = wrote: >>>>=20 >>>> 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker: >>>>=20 >>>> 5) Server presents certificate >>>>=20 >>>> Parse the certificate and find a DNS-CERT extension with prefix = _36fe829C >>>>=20 >>>> 6) Pull the DNS record to verify the certificate: >>>>=20 >>>> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y=3D=3D >>>> _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C >>>> >>>>=20 >>>> Since we know that the site uses DNSSEC, just don't bother checking = for >>>> DNS-CERT extension and instead lookup >>>> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR. >>>> Love >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Website: http://hallambaker.com/ >>=20 >>=20 >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ --Apple-Mail-465--622297800 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQXzoqZKwXOvvxymIt KZOH2DANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDQwMTAwMDAwMFoXDTExMDQwMTIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxHzAdBgNVBAMUFkxvdmUgSPZy bnF1aXN0IMVzdHJhbmQxGTAXBgkqhkiG9w0BCQEWCmxoYUBrdGguc2UwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDExzsEl8kHec1Flo6WDOR55uZ9e526lJpegh+pnb7kUoiMc3+L+oTM HbAQs4hOjUV1+kwPsdnBFolLJ6CR5lkwyZBHjzdbHMXnxh2czeIDjaD1lWxnEPTPefGZ0LEUgbix pThFfdW6wA9z43J/1VsZeQU8ZEY50ZHSkhjM+1PFdgjL5RJv2j7sFgHVr7P2mvEFNTy+PCKW/1Gj agjSehjXvFCqs8O9Was/dEdQ8pyT216VBPi+S77qcbGYAH6yqQ0XqiF0ogBZE8jKnkUDhFZz60gC QqlClW6i7iczbalEjnvEx3z+tsUzIK2UGrwqv0BmCg0qz7T1RZgbTowy0D/BAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAF01Bxe7vzqE /pJ4hZ30dqxJDSjHVOSmKdAkHg/i0uKLbIs7C+RYDlOptqlrmXwE40cTjFk26XVimzYayfHev/mA lgqxPlQC28zhQTHi1VtwVUXwslphpGRJk/WK8esXu61gGgjEErcGtNB7G4KfymM3yQgIudUM4cZb Z+5Et5fzLd9WLHIqd5vb2IbC4Q/dg00lmIWmikQtjt9mi1EaUUIAiySzjI5e6Akq8uyeOw+7ccPg WZOPPfif8D0z0WDXpSwCyTo9SG/f1gvwPkuxfJ4pilIBVBPkS2zAb7a5ZM1xXdLIjbboFCLCzJhk VsK40ZdKTdMvp9t/M1O1D/b7U+MxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fYMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNDA1 MjYyMFowIwYJKoZIhvcNAQkEMRYEFP1dnLwfJgeGTcWeItNqb/14HnoeMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEF86KmSsFzr78cpiLSmTh9gwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fY MA0GCSqGSIb3DQEBAQUABIIBADZqCxhNDxqSi+P8/cOc9ZnwSc1yHJESrjEVNsRdpJf1VGDLbd7H 1pA4//5i2PQjGoJzYJ/QhS1apBh/nouiyvMlUsolXbGIZJTTH3TzLHO+GBxtcAw8untOSyAltNEV lSBRQvTGcNdBYyymoBqlCJRirsTtg2Rj7OQToy5VXBp0Bavl8RFsCFcz4vkwyENbTzL8Q7c06q6D eQkBzI8kahEDEcKegV8gNSQA9FuyKmy62X4r2A7LRlFGEPArF3psAqsn5oiKYA938HM/UXbDm0D4 a3b0mFmnXDkRMZ6mr5fibHUWIxdxUflJiejWdTMDHeAZ4AWbKmutW+Vw+O1G/g4AAAAAAAA= --Apple-Mail-465--622297800-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E263A68DC for ; Mon, 23 Aug 2010 22:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-jvcAfyrv4q for ; Mon, 23 Aug 2010 22:09:48 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C8F073A68AD for ; Mon, 23 Aug 2010 22:09:48 -0700 (PDT) Received: by iwn3 with SMTP id 3so7000630iwn.31 for ; Mon, 23 Aug 2010 22:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KwpmcEjcmbfJepUDHeYrm/Sxtdb1g4goV3qEUQXtkMQ=; b=OSiiI1y8MiD+WJQxFxrYh9M1PYIKwqdhLDwj211cutccWBLH3snqC3CU/9TVkarYaR edXQ02tQrY5dB69tBMXshpzwK99ASw72n6nYa0CUQCdIhSlek/q9VllBobnaAJ3PtbKj Va+lc3Z87os3LMtC7PKVAGLBAEj3bvVCIs3zo= 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:content-transfer-encoding; b=Dh6dTb4m7Gh9N8l+ZgWrU1InbHVgkevE3bM24oVnDSko5yojr+aU1g05Bq4CIsCZDu D77ZOsR954YDE14gHQRespfAPX0CaHeG/hmy2arnl6SmoAIw9YlN5rqd5k1TUJSCxW6y sNsHkGxOiuL6TusnAoLLDPd42RqBgIerbrCU4= MIME-Version: 1.0 Received: by 10.231.174.84 with SMTP id s20mr7650358ibz.94.1282626622011; Mon, 23 Aug 2010 22:10:22 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Mon, 23 Aug 2010 22:10:21 -0700 (PDT) In-Reply-To: <3736A8F4-1A44-4967-AC3B-5F09F607B766@kth.se> References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <25DC9C15-669A-4ABD-A5B3-570C11FB5557@Princeton.EDU> <0894A13A-B6E3-4CD3-8482-AA1FD72E9090@kth.se> <3736A8F4-1A44-4967-AC3B-5F09F607B766@kth.se> Date: Tue, 24 Aug 2010 01:10:21 -0400 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 05:09:50 -0000 Hmm, I didn't put that in the ESRV I presented. It is certainly a possible design choice, the ESRV could have a flag to say 'DNSSEC validation', but that would tie the key discovery to my ESRV mechanism. Which seems like tying something relatively straightforward to something that I think has to be tailored to specific protocols... I did propose a version last week where I put the certhash in the ESRV record. But that was when I was trying to make everything work with a single record and calling it something else... On Tue, Aug 24, 2010 at 12:33 AM, Love H=F6rnquist =C5strand w= rote: > It said so in your newly proposed ESRV RR. > > Love > > > 23 aug 2010 kl. 21:23 skrev Phillip Hallam-Baker: > >> How do we know that the zone contains keys or certs at all? >> >> That would seem rather an odd assumption when no SSL certs are >> anchored in DNS at the moment. >> >> Knowing that the site has DNSSEC does not tell apps to look there for ke= ys. >> >> >> On Mon, Aug 23, 2010 at 11:58 PM, Love H=F6rnquist =C5strand wrote: >>> >>> 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker: >>> >>> 5) =A0Server presents certificate >>> >>> Parse the certificate and find a DNS-CERT extension with prefix _36fe82= 9C >>> >>> 6) Pull the DNS record to verify the certificate: >>> >>> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y=3D=3D >>> _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C >>> >>> >>> Since we know that the site uses DNSSEC, just don't bother checking for >>> DNS-CERT extension and instead lookup >>> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR. >>> Love >>> >>> >> >> >> >> -- >> Website: http://hallambaker.com/ > > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25AB3A681D for ; Mon, 23 Aug 2010 21:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5lq3M5wcCGa for ; Mon, 23 Aug 2010 21:33:17 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 270D93A6403 for ; Mon, 23 Aug 2010 21:33:15 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id E350914F101; Tue, 24 Aug 2010 06:33:18 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id 5GM5UPA0i7n4; Tue, 24 Aug 2010 06:33:18 +0200 (CEST) X-KTH-Auth: lha [71.158.241.78] X-KTH-mail-from: lha@kth.se Received: from [192.168.1.101] (adsl-71-158-241-78.dsl.pltn13.sbcglobal.net [71.158.241.78]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 748B814DCD0; Tue, 24 Aug 2010 06:33:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1162) Content-Type: multipart/signed; boundary=Apple-Mail-458--625486061; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: Date: Mon, 23 Aug 2010 21:33:11 -0700 Message-Id: <3736A8F4-1A44-4967-AC3B-5F09F607B766@kth.se> References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <25DC9C15-669A-4ABD-A5B3-570C11FB5557@Princeton.EDU> <0894A13A-B6E3-4CD3-8482-AA1FD72E9090@kth.se> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1162) Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 04:33:19 -0000 --Apple-Mail-458--625486061 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 It said so in your newly proposed ESRV RR. Love 23 aug 2010 kl. 21:23 skrev Phillip Hallam-Baker: > How do we know that the zone contains keys or certs at all? >=20 > That would seem rather an odd assumption when no SSL certs are > anchored in DNS at the moment. >=20 > Knowing that the site has DNSSEC does not tell apps to look there for = keys. >=20 >=20 > On Mon, Aug 23, 2010 at 11:58 PM, Love H=F6rnquist =C5strand = wrote: >>=20 >> 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker: >>=20 >> 5) Server presents certificate >>=20 >> Parse the certificate and find a DNS-CERT extension with prefix = _36fe829C >>=20 >> 6) Pull the DNS record to verify the certificate: >>=20 >> _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y=3D=3D >> _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C >> >>=20 >> Since we know that the site uses DNSSEC, just don't bother checking = for >> DNS-CERT extension and instead lookup >> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR. >> Love >>=20 >>=20 >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ --Apple-Mail-458--625486061 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQXzoqZKwXOvvxymIt KZOH2DANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDQwMTAwMDAwMFoXDTExMDQwMTIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxHzAdBgNVBAMUFkxvdmUgSPZy bnF1aXN0IMVzdHJhbmQxGTAXBgkqhkiG9w0BCQEWCmxoYUBrdGguc2UwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDExzsEl8kHec1Flo6WDOR55uZ9e526lJpegh+pnb7kUoiMc3+L+oTM HbAQs4hOjUV1+kwPsdnBFolLJ6CR5lkwyZBHjzdbHMXnxh2czeIDjaD1lWxnEPTPefGZ0LEUgbix pThFfdW6wA9z43J/1VsZeQU8ZEY50ZHSkhjM+1PFdgjL5RJv2j7sFgHVr7P2mvEFNTy+PCKW/1Gj agjSehjXvFCqs8O9Was/dEdQ8pyT216VBPi+S77qcbGYAH6yqQ0XqiF0ogBZE8jKnkUDhFZz60gC QqlClW6i7iczbalEjnvEx3z+tsUzIK2UGrwqv0BmCg0qz7T1RZgbTowy0D/BAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAF01Bxe7vzqE /pJ4hZ30dqxJDSjHVOSmKdAkHg/i0uKLbIs7C+RYDlOptqlrmXwE40cTjFk26XVimzYayfHev/mA lgqxPlQC28zhQTHi1VtwVUXwslphpGRJk/WK8esXu61gGgjEErcGtNB7G4KfymM3yQgIudUM4cZb Z+5Et5fzLd9WLHIqd5vb2IbC4Q/dg00lmIWmikQtjt9mi1EaUUIAiySzjI5e6Akq8uyeOw+7ccPg WZOPPfif8D0z0WDXpSwCyTo9SG/f1gvwPkuxfJ4pilIBVBPkS2zAb7a5ZM1xXdLIjbboFCLCzJhk VsK40ZdKTdMvp9t/M1O1D/b7U+MxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fYMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNDA0 MzMxMlowIwYJKoZIhvcNAQkEMRYEFANfG4jecagG4TQbFu4XuUJNKzuGMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEF86KmSsFzr78cpiLSmTh9gwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fY MA0GCSqGSIb3DQEBAQUABIIBAHmmLBrimASFxgAZ5GtkH8MaCSE3BjndN8dpCzEA1s2mBp715AjI ukQIbgnj4F69+Uw7TzWvdbzKZ6D0b6EELzed0SnezlIOmcnmjobCYz68MYEla8TuRyeuVUwcOswT gPMKY9FrV8EnCg0bM8xQOhoOYpazdi/oHy2raV8eU5RbNDHPNhCLZ65Z/UvWTF+eiqHzTjBEAulD U+ESEyOXXLYXVTmKdaunKmYrTho53wjWxQ6BSlno4gD3siJTAJSqXmZCFhvcD67YplA/CgM8ru3P kTHlC94gdkQUUiAjMrou4rzbNOvIxsgJFibFNskTJNcOSnMcD16HFc5D46miq/gAAAAAAAA= --Apple-Mail-458--625486061-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38DA3A6405 for ; Mon, 23 Aug 2010 21:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUz+usGnuUo5 for ; Mon, 23 Aug 2010 21:23:19 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B1D353A6845 for ; Mon, 23 Aug 2010 21:23:19 -0700 (PDT) Received: by iwn3 with SMTP id 3so6967559iwn.31 for ; Mon, 23 Aug 2010 21:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Y9cQ6dvB9/KGIAdMc/35OxJvohMhiX46RBrYb2CcH/s=; b=uiAm+GSQAyYI+8rC4c1oulWOqJt5rf7UEHXS6jOR+Q7uWNnDKx6sW9fm5BQQFjD03v tJsY0Zl9mDAvXRjMQqYWoZ242ujpL47TGJoO2cyBu/IWwHq67kR6RXHfheEAtptn10jB r/aihyGlRWfZX5UxpUe1pbejj92KJNR1oyYnU= 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:content-transfer-encoding; b=IO2XBQNDi9InSVro+iIzXbP5vM2FDyh+qOEWiCJDNI/yAtopp0yWGCYZhgbTDDrZ/b 5cwXy+GXCDb1m0G+d7V5ferreWH6oEw0jv5RkCHkGqVf8alStm9h7BsnPJd3seOg65+e lzfQxaPcNitnimhrKlu5UL5bqKUiWgH5upGi0= MIME-Version: 1.0 Received: by 10.231.153.76 with SMTP id j12mr5728646ibw.66.1282623829998; Mon, 23 Aug 2010 21:23:49 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Mon, 23 Aug 2010 21:23:49 -0700 (PDT) In-Reply-To: <0894A13A-B6E3-4CD3-8482-AA1FD72E9090@kth.se> References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <25DC9C15-669A-4ABD-A5B3-570C11FB5557@Princeton.EDU> <0894A13A-B6E3-4CD3-8482-AA1FD72E9090@kth.se> Date: Tue, 24 Aug 2010 00:23:49 -0400 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 04:23:20 -0000 How do we know that the zone contains keys or certs at all? That would seem rather an odd assumption when no SSL certs are anchored in DNS at the moment. Knowing that the site has DNSSEC does not tell apps to look there for keys. On Mon, Aug 23, 2010 at 11:58 PM, Love H=F6rnquist =C5strand w= rote: > > 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker: > > 5) =A0Server presents certificate > > Parse the certificate and find a DNS-CERT extension with prefix _36fe829C > > 6) Pull the DNS record to verify the certificate: > > _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y=3D=3D > _36fe829C.host2.example.com CERT 1 8=A0http://ca.example.com/36fe829C > > > Since we know that the site uses DNSSEC, just don't bother checking for > DNS-CERT extension and instead lookup > HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR. > Love > > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E2E3A6405 for ; Mon, 23 Aug 2010 20:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ks5vGpKce4zu for ; Mon, 23 Aug 2010 20:58:24 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 61B863A6403 for ; Mon, 23 Aug 2010 20:58:24 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 78E4514F101; Tue, 24 Aug 2010 05:58:26 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id JgX1PSzzNoCH; Tue, 24 Aug 2010 05:58:25 +0200 (CEST) X-KTH-Auth: lha [71.158.241.78] X-KTH-mail-from: lha@kth.se Received: from [192.168.1.101] (adsl-71-158-241-78.dsl.pltn13.sbcglobal.net [71.158.241.78]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 6599C14DCD0; Tue, 24 Aug 2010 05:58:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1162) Content-Type: multipart/signed; boundary=Apple-Mail-455--627580201; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: Date: Mon, 23 Aug 2010 20:58:17 -0700 Message-Id: <0894A13A-B6E3-4CD3-8482-AA1FD72E9090@kth.se> References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <25DC9C15-669A-4ABD-A5B3-570C11FB5557@Princeton.EDU> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1162) Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 03:58:25 -0000 --Apple-Mail-455--627580201 Content-Type: multipart/alternative; boundary=Apple-Mail-454--627580254 --Apple-Mail-454--627580254 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 23 aug 2010 kl. 13:45 skrev Phillip Hallam-Baker: > 5) Server presents certificate >=20 > Parse the certificate and find a DNS-CERT extension with prefix = _36fe829C >=20 > 6) Pull the DNS record to verify the certificate: >=20 > _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y=3D=3D > _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C > Since we know that the site uses DNSSEC, just don't bother checking for = DNS-CERT extension and instead lookup = HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR. Love --Apple-Mail-454--627580254 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
5) =  Server presents certificate

Parse the certificate and find = a DNS-CERT extension with prefix _36fe829C

6) Pull the DNS record = to verify the certificate:

_36fe829C.host2.example.com CERT 1 9 = 2i3uh298yq2f23fhq2398y=3D=3D
_36fe829C.host2.example.com CERT 1 = 8 http://ca.example.com/36fe829C=
<SIG for above>

Since we = know that the site uses DNSSEC, just don't bother checking for DNS-CERT = extension and instead lookup = HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT = RR.

Love


= --Apple-Mail-454--627580254-- --Apple-Mail-455--627580201 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQXzoqZKwXOvvxymIt KZOH2DANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDQwMTAwMDAwMFoXDTExMDQwMTIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxHzAdBgNVBAMUFkxvdmUgSPZy bnF1aXN0IMVzdHJhbmQxGTAXBgkqhkiG9w0BCQEWCmxoYUBrdGguc2UwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDExzsEl8kHec1Flo6WDOR55uZ9e526lJpegh+pnb7kUoiMc3+L+oTM HbAQs4hOjUV1+kwPsdnBFolLJ6CR5lkwyZBHjzdbHMXnxh2czeIDjaD1lWxnEPTPefGZ0LEUgbix pThFfdW6wA9z43J/1VsZeQU8ZEY50ZHSkhjM+1PFdgjL5RJv2j7sFgHVr7P2mvEFNTy+PCKW/1Gj agjSehjXvFCqs8O9Was/dEdQ8pyT216VBPi+S77qcbGYAH6yqQ0XqiF0ogBZE8jKnkUDhFZz60gC QqlClW6i7iczbalEjnvEx3z+tsUzIK2UGrwqv0BmCg0qz7T1RZgbTowy0D/BAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAF01Bxe7vzqE /pJ4hZ30dqxJDSjHVOSmKdAkHg/i0uKLbIs7C+RYDlOptqlrmXwE40cTjFk26XVimzYayfHev/mA lgqxPlQC28zhQTHi1VtwVUXwslphpGRJk/WK8esXu61gGgjEErcGtNB7G4KfymM3yQgIudUM4cZb Z+5Et5fzLd9WLHIqd5vb2IbC4Q/dg00lmIWmikQtjt9mi1EaUUIAiySzjI5e6Akq8uyeOw+7ccPg WZOPPfif8D0z0WDXpSwCyTo9SG/f1gvwPkuxfJ4pilIBVBPkS2zAb7a5ZM1xXdLIjbboFCLCzJhk VsK40ZdKTdMvp9t/M1O1D/b7U+MxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fYMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNDAz NTgxOFowIwYJKoZIhvcNAQkEMRYEFHyg2hFqdOKP51bd3+jLzFhKHhwNMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEF86KmSsFzr78cpiLSmTh9gwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fY MA0GCSqGSIb3DQEBAQUABIIBAF5BWqE1JUjFwuaVQ6BNNNBN+6Ey8BnGQODCJOc+p2dO69N6/Qdl 7S5vcZiBnksfNIdQgu0wofnUNyEYOejvlQ5IMETn2wo2g3LSnAFqlCZkcMSZiwrP3Ie189ljoGP+ VSb1IaT6khkB2utMyzWVaJTxcSOWjAFVeDw/u0RwPwG86iNvv6APChrY8Md7Q8TLhKmquWXJTAfc HR2MxF4dCltgY0T43P6IrLpmbOcvalgo/ZUZlYdxLdtDgINzLWUqztqoeR9QSb6ns9o26i0um/i8 epfJVcDf97VrQiwbMXkVwSdQiag/a6gDyu8zpLmopNfYZfgJxTxOGyTeenh8Fh8AAAAAAAA= --Apple-Mail-455--627580201-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311093A67FE for ; Mon, 23 Aug 2010 15:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyJCH8kH1peR for ; Mon, 23 Aug 2010 15:36:04 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 4EBB23A6958 for ; Mon, 23 Aug 2010 15:36:03 -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 58159C17D; Mon, 23 Aug 2010 18:36:36 -0400 (EDT) Date: Mon, 23 Aug 2010 18:36:35 -0400 (EDT) From: Paul Wouters To: keyassure@ietf.org Message-ID: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Paul Hoffman Subject: [keyassure] comments on draft-hoffman-keys-linkage-from-dns-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 22:36:11 -0000 My comments on draft-hoffman-keys-linkage-from-dns-00.txt, In section 2, three alternatives are proposed. I prefer alternative number two (The TLSFP Resource Record). I am curious why no sub-typing was suggested. Instead of getting a list of port numbers, would it not be better to request the TLSFP RR for a specific port? Was this done to make adoption easier by not requiring a new kind of subtype query? Or is there a more fundamental DNS reason for this pick? And if subtype queries are to be avoided, would it not be an option to use a _protocol._port. entry to avoid returning multiple options that a client then has to dig through? Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3653A6B1D for ; Mon, 23 Aug 2010 14:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bx+y1OSblyc for ; Mon, 23 Aug 2010 14:12:51 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 92C9F3A6B26 for ; Mon, 23 Aug 2010 14:12:22 -0700 (PDT) Received: by iwn3 with SMTP id 3so6605882iwn.31 for ; Mon, 23 Aug 2010 14:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tFqTw/Jj2NkJ19Nv+eJm/2uS4/k5PtGW5uA6SjABluc=; b=ruBF/k/0ZB+KzVXYPc06Vhvp6uXB56N6z6kbnV/jb1XoD5gy2qowThEsu7soTWmHVk eHtt5Pkr1IulfcjzfjwRhO82nWem/laAnPzMX5t0ZzIZln7NdJqErQRPG4BqN5FZyAlB oKwEbEs6Zi/ovuz6728IZtcx28doHzF1UYoxg= 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=LjGtthvXbpV7Hf9v5kU4ye6/ryWpzKN7yYGz+0mXefY5NHcNv3fsuUE3f2oUBTPb9P 1r8gOKVSKoMf1yeCoPAPXhZakXDhEmIQnyByDjIfmi1C/uamnwOFPJCNr1KvtoLc8UO7 EVNTCYUcY9SbhuGxdYUgiunSXVUgmLNC6FjwE= MIME-Version: 1.0 Received: by 10.231.31.200 with SMTP id z8mr6848009ibc.90.1282597968314; Mon, 23 Aug 2010 14:12:48 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Mon, 23 Aug 2010 14:12:48 -0700 (PDT) In-Reply-To: References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <7C407E48-9E99-44CB-BA31-306C0574E15F@Princeton.EDU> Date: Mon, 23 Aug 2010 17:12:48 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 21:12:56 -0000 On Mon, Aug 23, 2010 at 4:18 PM, Paul Wouters wrote: > On Mon, 23 Aug 2010, Stephen Schultze wrote: > Yes, we are talking about a changed security assumption, regardless of what > this > group decides. We can avoid stepping on the PKIX toes - by not using PKIX. No, you tread on our toes by ignoring our work and repeating our mistakes. > I guess we really need to step back and decide the problem we're solving. > People > are definitely solving totally different problems right now. Since my reading of 5395 is that the criteria for issuing a new code point to CERT are essentially the same as the criteria for issuing a new code point for a resource record, it seems to me that we will either have a CERT hash function for complete certs or we will have one for complete certs and a second one for keys in certs. -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D67F3A6AF9 for ; Mon, 23 Aug 2010 13:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HvJ1s-zzmsB for ; Mon, 23 Aug 2010 13:45:27 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id C387E3A6AF4 for ; Mon, 23 Aug 2010 13:45:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=BEFJm8xPS9qmOrkNo5co222Grjek3wtv2Y9oCt0MZKqO/cAQTrGzLroon5hB+RdR; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Ondu4-0002ua-4b; Mon, 23 Aug 2010 16:46:00 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 23 Aug 2010 16:45:59 -0400 Message-ID: <12242682.1282596360051.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Mon, 23 Aug 2010 15:45:59 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Stephen Schultze , keyassure@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688211bce140fa997d8893dc9935a9972dc350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 20:45:28 -0000 Stephen and all, -----Original Message----- >From: Stephen Schultze >Sent: Aug 23, 2010 2:54 PM >To: keyassure@ietf.org >Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt > >On Aug 23, 2010, at 3:45 PM, Nicholas Weaver wrote: >>>> b) It requires that all validators understand the semantics of >>>> the certificates rather than just treating them as opaque binary >>>> blobs. >>> >>> Certainly not all DNSSEC validators (that's what you seem to be >>> implying below). Only the TLS module needs to be changed to first >>> pull out the key. The rest of the DNSSEC chain works as normal. >> >> Except the model existing for DNSSEC is that an ARBITRARY RR can be >> validated by any DNSSEC cache or intermediatry. By only validating >> a portion of the data, you break this model for no benefit: such an >> RR would be very different from every other resource record in terms >> of validation by intermediaries: DNS has the property that any >> unknown record type should be treatable as an opaque blob of bits, >> including for the purpose of validation. > >One of us is radically misunderstanding the other. It could be my >fault. > >The idea is that the DNSSEC validates the RR, just the same as any >other. This gives you a trusted key. > >Then, in the course of TLS setup (for example), the client takes the >key that it got from the RR and compares that with the key it's >getting from the server (embedded in a cert or otherwise). This is >happening in client libs, which might indeed need to be updated. > >None of this implicates changes to DNSSEC operations. > >What am I missing? I don't think your missing anything here. Well done! >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D733A6AF9 for ; Mon, 23 Aug 2010 13:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUXUEteaZ4rn for ; Mon, 23 Aug 2010 13:45:09 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 2C4F23A6AFC for ; Mon, 23 Aug 2010 13:45:08 -0700 (PDT) Received: by yxk8 with SMTP id 8so2725749yxk.31 for ; Mon, 23 Aug 2010 13:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TmdTrZwTlEbbZRTH88BGwf0NeUDPs0NTxGX13iIzSrQ=; b=k7f6W2/NLZyIbIfnoKJXgIIEzGA7pV/5ZSoMK9+rJf+z6cKglQ6WohAuJIVCPQD5GM pGHLVSwJphWLfYFuqdNJIwdBCnKoV6ebyZa31d8Zz6Jrn91CI2gw4KGGsl5B+c3r6l2q QKK5TRsTW0mnvKQS+Dk/OACkDFtMhbvbSWgd8= 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:content-transfer-encoding; b=KBeSmm8didETTst7r0ApMv0wOO6OnqVemo/baqmwjpG5Tc4I1TS0i33U5RXjqh0nWM 5nZpt4Q76KuZUZ/9oDCWd55ktM6ffUIscuhesKZv/KhmWJrBmiGUCvUGkbCgvKafbOrA AY/bpok+cKit/zml1hU/GNfLZBFnQitXxfAbE= MIME-Version: 1.0 Received: by 10.151.62.9 with SMTP id p9mr6038760ybk.122.1282596341653; Mon, 23 Aug 2010 13:45:41 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Mon, 23 Aug 2010 13:45:41 -0700 (PDT) In-Reply-To: <25DC9C15-669A-4ABD-A5B3-570C11FB5557@Princeton.EDU> References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <25DC9C15-669A-4ABD-A5B3-570C11FB5557@Princeton.EDU> Date: Mon, 23 Aug 2010 16:45:41 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Schultze Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 20:45:11 -0000 On Mon, Aug 23, 2010 at 3:15 PM, Stephen Schultze wrote= : > On Aug 23, 2010, at 2:42 PM, Phillip Hallam-Baker wrote: >>> >>> Combining your approach with an >>> approach that simply seeks to enable validated domain-to-key mapping >>> based >>> on the properties of DNSSEC itself has the following disadvantages: >>> >>> 1. mixing together assertions that require different authority >>> 2. locking in applications to either implementing the cert format you >>> choose, or adding duplicative cert hash DNS entries for each new cert >>> format >> >> Actually, this appears to me to be the disadvantage of requiring the >> DNS systems to pull out the key from the cert. > > Can you explain? =A0I'm not grokking. At present, pretty much every SSL library consists of code to replace open(x) with openssl(x, callback, param) The callback code throws the calling application a bundle of certs and a context pointer passed in at the top. The callback has to then decide whether it likes the taste of the cert or not and respond accordingly. As the term Secure Socket Library implies, this is totally wired into the architecture of the protocol, it is what the patent was granted for (cue ironic laughter). So if you want to isolate the callback code from messing with ASN.1, you want to allow them to treat the cert as simply a raw binary blob to munch on with a digest function. The SSL library code they are using already has the code necessary for extracting the key. >>>> the reason we are using certs and not just keys is because we need >>>> those additional bits. >>> >>> I think that the additional bits needed for fully featured operation of >>> domain-to-key mapping (eg: "require SSL") can be easily built into the >>> spec, >>> whereas bits that assert other things can still ride in the cert itself >>> and >>> be validated by whoever signs the cert (if anyone). >> >> Logically speaking, you need to know about 'require SSL' before you >> start processing the certificate that was presented in the SSL >> transaction. > > Is the same not true for knowing whether the cert (or key) you were > presented with hashes to what's in DNS? =A0If so, the blocking is the sam= e. > =A0You have to wait until you get the RR. In the full version of my preferred architecture, the client does the following when it wants to create a connection for (domain, service). e.g. ("example.com", "_http._tcp") 1) Pull the ESRV record for the service _http._tcp.example.com ESRV "tls=3Doptional discovery=3Dsrv" 2) Client supports the SRV discovery option so we pull that record as well: _https._tcp.example.com SRV 1 1 443 host1.example.com _https._tcp.example.com SRV 1 1 443 host2.example.com 3) Try host2: host2.example.com A 10.1.1.1 4) Open the SSL tunnel to 10.1.1.1 port 443 5) Server presents certificate Parse the certificate and find a DNS-CERT extension with prefix _36fe829C 6) Pull the DNS record to verify the certificate: _36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y=3D=3D _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C Note that at every stage we have a completely defined search set. We have no hunting around for the next link in the chain. The SRV step is optional of course. And for some protocols we might want to use NAPTR or some other SRV variant. Yes, this approach is not all within scope of what others on this list are looking to build. But in my approach to protocol design I look at the total functionality I want and then go about looking to see how I divide it up into technology platforms. I do not start with a technology platform and try to enumerate the maximum possible number of nails to bash with it. HTTP should have had SRV and SSL designed in from the start. I don't think you want to include ESRV functionality in the CERT record because it has to be tuned to the specific protocol. --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB49D3A6AF2 for ; Mon, 23 Aug 2010 13:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMHWkUFmyB3x for ; Mon, 23 Aug 2010 13:37:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 7EF693A6B0A for ; Mon, 23 Aug 2010 13:34:35 -0700 (PDT) Received: from ros-dhcp192-1-51-64.bbn.com ([192.1.51.64]:55293) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ondie-000L2C-MK; Mon, 23 Aug 2010 16:34:12 -0400 Message-Id: <5E23DDC6-D614-4AF2-967A-1A7BB19DBFE4@bbn.com> From: "Richard L. Barnes" To: Paul Wouters In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 16:34:11 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <7C407E48-9E99-44CB-BA31-306C0574E15F@Princeton.EDU> X-Mailer: Apple Mail (2.936) Cc: Stephen Schultze , keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 20:37:39 -0000 X-List-Received-Date: Mon, 23 Aug 2010 20:37:39 -0000 >>> Data authorisation duplication is an extremely bad idea. Multiple >>> authorities >>> could give different answers and then what do you end up doing? >>> Again, it >>> makes no sense to reproduce X.509 in DNS and then use out-of- >>> bounds CA >>> validation requirements. >> >> This is going to be an issue regardless of the decision on this >> issue. What do you do if you have an expired or revoked >> certificate/key that nevertheless has a valid hash in DNS? > > Only when using X.509 containers. i've been advocating against those. This question seems irrelevant to what sort of container you use. If you have a key or fingerprint that's still in the zone, but the cert that's presented at the application layer is expired or revoked, is it still considered valid? There's a little bit of an operational concern here in that you can keep the same key pair while changing the cert, but it doesn't seem like a huge deal to add "update CERT in DNS" to the TODO list when you're rolling over your cert. >>> That's right. We no longer trust CA's. That's a feature, not a bug. >> >> Agreed, but it is a bug if somehow we end up allowing controllers >> of zones to make and have validated assertions for things that they >> shouldn't be trusted for, or if we create ambiguity about who is >> asserting what. As such, if we end up cherry-picking fields from X. >> 509 we need to specify clearly what it means in this regard. > > Again, no cherry picking. key hashes in the DNS with flags/options > fields. Validity > is determined by the presense in the zone with a valid DNSSEC > signature. As above, the question of validity is independent of the question of which container is used. Expired or revoked certificates can still be used as trust anchors, so even if the cert in the DNS is expired/ revoked, it can still be considered "good" if it's DNSSEC-validated. >> In any case, my point was obviously that in either scenario we are >> presuming a changed security assumption, which was Phillip's >> objection. > > Yes, we are talking about a changed security assumption, regardless > of what this > group decides. We can avoid stepping on the PKIX toes - by not using > PKIX. > > I guess we really need to step back and decide the problem we're > solving. People > are definitely solving totally different problems right now. Agree on all points here. What we're proposing is an adjunct, parallel validation path to PKIX. As to deciding what problem we're solving, I've tried to express my idea of the problem in a charter proposal: --Richard Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3193A689B for ; Mon, 23 Aug 2010 13:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb7ZCt6kyvAg for ; Mon, 23 Aug 2010 13:17:41 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 280CE3A67D0 for ; Mon, 23 Aug 2010 13:17:41 -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 EC22EBC07; Mon, 23 Aug 2010 16:18:12 -0400 (EDT) Date: Mon, 23 Aug 2010 16:18:12 -0400 (EDT) From: Paul Wouters To: Stephen Schultze In-Reply-To: Message-ID: References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <7C407E48-9E99-44CB-BA31-306C0574E15F@Princeton.EDU> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 20:17:42 -0000 On Mon, 23 Aug 2010, Stephen Schultze wrote: >> Data authorisation duplication is an extremely bad idea. Multiple >> authorities >> could give different answers and then what do you end up doing? Again, it >> makes no sense to reproduce X.509 in DNS and then use out-of-bounds CA >> validation requirements. > > This is going to be an issue regardless of the decision on this issue. What > do you do if you have an expired or revoked certificate/key that nevertheless > has a valid hash in DNS? Only when using X.509 containers. i've been advocating against those. >> That's right. We no longer trust CA's. That's a feature, not a bug. > > Agreed, but it is a bug if somehow we end up allowing controllers of zones to > make and have validated assertions for things that they shouldn't be trusted > for, or if we create ambiguity about who is asserting what. As such, if we > end up cherry-picking fields from X.509 we need to specify clearly what it > means in this regard. Again, no cherry picking. key hashes in the DNS with flags/options fields. Validity is determined by the presense in the zone with a valid DNSSEC signature. > In any case, my point was obviously that in either scenario we are presuming > a changed security assumption, which was Phillip's objection. Yes, we are talking about a changed security assumption, regardless of what this group decides. We can avoid stepping on the PKIX toes - by not using PKIX. I guess we really need to step back and decide the problem we're solving. People are definitely solving totally different problems right now. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376733A6AD2 for ; Mon, 23 Aug 2010 13:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuGsTg6A3B+e for ; Mon, 23 Aug 2010 13:04:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 18D443A67D0 for ; Mon, 23 Aug 2010 13:04:11 -0700 (PDT) Received: from ros-dhcp192-1-51-64.bbn.com ([192.1.51.64]:54750) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OndG8-000KW4-5Y for keyassure@ietf.org; Mon, 23 Aug 2010 16:04:44 -0400 Message-Id: From: "Richard L. Barnes" To: keyassure@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 16:04:43 -0400 X-Mailer: Apple Mail (2.936) Subject: [keyassure] Sample code X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 20:04:12 -0000 Speaking, as Phillip was, of the importance of people writing code, here's a little bit of sample code that illustrates why it's handy to have the full cert in the DNS. (Even though it is, I acknowledge, more than one needs, and does raise issues with certificate expiry.) Namely, you can reduce implementation of DNSSEC-assured TLS keying to around 10 lines. CAVEAT EMPTOR: I haven't tested this, but at least it compiles and links against libunbound and openssl. -----BEGIN----- #include #include void keyassure(char *name, SSL_CTX *ctx) { // Obtain the CERT record from DNS, secured with DNSSEC struct ub_ctx *dns_ctx = ub_ctx_create(); struct ub_result *result; ub_resolve( dns_ctx, name, 37, // TYPE CERT 1, // CLASS IN &result ); // If we got a DNSSC-signed CERT record, add it to the SSL CA list if (result->secure && result->havedata) { // Read the X509 bytes into an OpenSSL X509 object // Skip 5 bytes of type/tag/algorithm in the rrdata unsigned char *cert_data = (unsigned char*) result->data[0] + 5; int cert_len = result->len[0] - 5; X509* cert = d2i_X509(NULL, cert_data, cert_len); // Mark the cert as a trusted CA cert SSL_add_client_CA(ctx, cert); } } int main(int argc, char **argv) { if (argc < 2) return 1; SSL_CTX *ctx = SSL_CTX_new(TLSv1_method()); keyassure(argv[1], ctx); // Finish setting up context and make SSL connection... } -----END----- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683743A6AEB for ; Mon, 23 Aug 2010 13:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dd10IcUXLsT5 for ; Mon, 23 Aug 2010 13:00:45 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 6E8B63A6AE8 for ; Mon, 23 Aug 2010 13:00:45 -0700 (PDT) Received: by pvg7 with SMTP id 7so2819392pvg.31 for ; Mon, 23 Aug 2010 13:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=GwPOGEHypW5TaQsnxIuaN4vuiiptlmudM1pxUCQIYrU=; b=PUu0KE9S7sIOmT05JtwSonTzRpzkKcD50oOhtF021HgoJYEnj9WAQyIqTN0lfIZlxN loVEN84EszvDhV1X9Boo4KpkMXx3hWxvTbHHlctv7Mc8Udz+t/IFQS2JNJxHlWAh670E IXSaty+GZEeW2oNp9P306C2ntdK7NE0212mQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=czGmxkaJjwpXkv6/fpb/GGeZWmmU0fxk04Ke/I1dbsSm8vtiGb1CKuIkgVpm0EcGW7 Ay3MSLbq2YLlU2kJrBIv7gMaxEp3j6vVFzQuKfZ6Yz3AaPZHxQuQzpaigGBQKKKu1JvN 0gtH5OfYCMQSoaeksdEOP/lfdTC5WKXQVT5HU= Received: by 10.142.44.14 with SMTP id r14mr4918611wfr.76.1282593678881; Mon, 23 Aug 2010 13:01:18 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id t11sm8903049wfc.16.2010.08.23.13.01.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Aug 2010 13:01:17 -0700 (PDT) Sender: Nicholas Weaver References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <5E5BB1D2-B6B0-4632-B6F7-51244FDDE5A7@icsi.berkeley.edu> <64D01BFB-8CCC-4884-9124-1ED70E7EF924@Princeton.EDU> <4D6168A2-7446-46F1-ACFC-095EFC47684E@icsi.berkeley.edu> <8FE6D0DD-3B5D-44F7-B695-E589BF4C6714@Princeton.EDU> In-Reply-To: <8FE6D0DD-3B5D-44F7-B695-E589BF4C6714@Princeton.EDU> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <911909A7-06F0-4EF6-9B8B-B5527972E6B4@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Mon, 23 Aug 2010 13:01:15 -0700 To: Stephen Schultze X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 20:00:46 -0000 On Aug 23, 2010, at 12:54 PM, Stephen Schultze wrote: > On Aug 23, 2010, at 3:45 PM, Nicholas Weaver wrote: >>>> b) It requires that all validators understand the semantics of the = certificates rather than just treating them as opaque binary blobs. >>>=20 >>> Certainly not all DNSSEC validators (that's what you seem to be = implying below). Only the TLS module needs to be changed to first pull = out the key. The rest of the DNSSEC chain works as normal. >>=20 >> Except the model existing for DNSSEC is that an ARBITRARY RR can be = validated by any DNSSEC cache or intermediatry. By only validating a = portion of the data, you break this model for no benefit: such an RR = would be very different from every other resource record in terms of = validation by intermediaries: DNS has the property that any unknown = record type should be treatable as an opaque blob of bits, including for = the purpose of validation. >=20 > One of us is radically misunderstanding the other. It could be my = fault. >=20 > The idea is that the DNSSEC validates the RR, just the same as any = other. This gives you a trusted key. >=20 > Then, in the course of TLS setup (for example), the client takes the = key that it got from the RR and compares that with the key it's getting = from the server (embedded in a cert or otherwise). This is happening in = client libs, which might indeed need to be updated. >=20 > None of this implicates changes to DNSSEC operations. >=20 > What am I missing? I guess I got confused by the discussion that DNSSEC only validates = parts of the certificate. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF183A6ABC for ; Mon, 23 Aug 2010 12:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.054 X-Spam-Level: X-Spam-Status: No, score=-6.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKSOxW-z0POt for ; Mon, 23 Aug 2010 12:54:17 -0700 (PDT) Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id 33E4A3A6A7D for ; Mon, 23 Aug 2010 12:54:17 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7NJsoIc009556 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Aug 2010 15:54:50 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7NJsn5F016565 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 15:54:50 -0400 (EDT) Message-Id: <8FE6D0DD-3B5D-44F7-B695-E589BF4C6714@Princeton.EDU> From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: <4D6168A2-7446-46F1-ACFC-095EFC47684E@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 15:54:49 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <5E5BB1D2-B6B0-4632-B6F7-51244FDDE5A7@icsi.berkeley.edu> <64D01BFB-8CCC-4884-9124-1ED70E7EF924@Princeton.EDU> <4D6168A2-7446-46F1-ACFC-095EFC47684E@icsi.berkeley.edu> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6083 signatures=637993 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008230161 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:54:18 -0000 On Aug 23, 2010, at 3:45 PM, Nicholas Weaver wrote: >>> b) It requires that all validators understand the semantics of >>> the certificates rather than just treating them as opaque binary >>> blobs. >> >> Certainly not all DNSSEC validators (that's what you seem to be >> implying below). Only the TLS module needs to be changed to first >> pull out the key. The rest of the DNSSEC chain works as normal. > > Except the model existing for DNSSEC is that an ARBITRARY RR can be > validated by any DNSSEC cache or intermediatry. By only validating > a portion of the data, you break this model for no benefit: such an > RR would be very different from every other resource record in terms > of validation by intermediaries: DNS has the property that any > unknown record type should be treatable as an opaque blob of bits, > including for the purpose of validation. One of us is radically misunderstanding the other. It could be my fault. The idea is that the DNSSEC validates the RR, just the same as any other. This gives you a trusted key. Then, in the course of TLS setup (for example), the client takes the key that it got from the RR and compares that with the key it's getting from the server (embedded in a cert or otherwise). This is happening in client libs, which might indeed need to be updated. None of this implicates changes to DNSSEC operations. What am I missing? Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D62D3A6AB1 for ; Mon, 23 Aug 2010 12:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPLeRYPE-TYm for ; Mon, 23 Aug 2010 12:48:13 -0700 (PDT) Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id DAD353A6A7D for ; Mon, 23 Aug 2010 12:48:12 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id o7NJmjIP003782 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Aug 2010 15:48:46 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7NJmjpF019062 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 15:48:45 -0400 (EDT) Message-Id: From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: <850D9F1E-094F-4FA4-9B2D-445C1844A14D@bbn.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 15:48:45 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <850D9F1E-094F-4FA4-9B2D-445C1844A14D@bbn.com> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6083 signatures=637993 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008230160 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:48:14 -0000 On Aug 23, 2010, at 3:00 PM, Richard L. Barnes wrote: >> That is close but I don't think we can reuse the CERT record and then >> put policy information in it such as 'SSL required'. >> >> That should be separated out into another record. Otherwise we end up >> treating CERT in the same manner as TXT has been (ab)used. > > Definitely agree with not using CERT for that sort of policy > information, but I would go further to say that policy isn't the > domain of this group. The definition of "SSL required" will vary > quite a bit between applications, so policy work is more > appropriately done in more application-specific groups, such as the > proposed HASMAT group for HTTP: > Looking to HSTS is a good idea, and it makes sense to look at actual implementations too (including to understand its limitations), eg: http://dev.chromium.org/sts That approach would also argue for keeping any of these assertions out of the same X.509 certs that carry other third-party assertions. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A943A6AB8 for ; Mon, 23 Aug 2010 12:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.661, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGRdOb9WT95F for ; Mon, 23 Aug 2010 12:44:42 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 78F293A6A7D for ; Mon, 23 Aug 2010 12:44:42 -0700 (PDT) Received: by pvg7 with SMTP id 7so2813419pvg.31 for ; Mon, 23 Aug 2010 12:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=dAQ+aT6paKdnjezzGlbUGQ5b1p6rK2DCMdn70jR8OvA=; b=LT+Ma9cxYy++1HvxK7Rb3GROFLYB9vN2JP0prHUx1fFkkTKScTuay9A8lmokNsmdrL A51qdVdH5PTB4tAI8c0tagPcmm+RXSEX+JRhcuPSnmEFVtkJdxGdO4Qv5pc6iuqvWJ3Z Uk54QocT4CcPFqcWLEoddlW9mi594z67JAbf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=nQ1RgaPK/xhGBwFRBAb5OB4KrUZ4PIUNsVSHsyRKH1CWVClJn447E+7MlfuhrGHHy+ Mly+BhFUKamJ77jg9C9uL2xKUKqUrIbDxfe82CYxC3wpdxrDASmeNV+EU57K9+M8RtM6 47OSPf2LFwhagTmQTjiskSlzN8R+mksGEheiA= Received: by 10.142.180.20 with SMTP id c20mr4822665wff.136.1282592715685; Mon, 23 Aug 2010 12:45:15 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id y16sm8885667wff.14.2010.08.23.12.45.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Aug 2010 12:45:14 -0700 (PDT) Sender: Nicholas Weaver References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <5E5BB1D2-B6B0-4632-B6F7-51244FDDE5A7@icsi.berkeley.edu> <64D01BFB-8CCC-4884-9124-1ED70E7EF924@Princeton.EDU> In-Reply-To: <64D01BFB-8CCC-4884-9124-1ED70E7EF924@Princeton.EDU> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <4D6168A2-7446-46F1-ACFC-095EFC47684E@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Mon, 23 Aug 2010 12:45:11 -0700 To: Stephen Schultze X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:44:44 -0000 On Aug 23, 2010, at 12:21 PM, Stephen Schultze wrote: > On Aug 23, 2010, at 2:58 PM, Nicholas Weaver wrote: >> On Aug 23, 2010, at 11:51 AM, Stephen Schultze wrote: >>> On Aug 23, 2010, at 1:18 PM, Phillip Hallam-Baker wrote: >>>>> The DNS location can show the permitted use. DNSSEC can provide = the >>>>> validation for that. >>>>=20 >>>> So now your proposal is >>>>=20 >>>> 1) Only sign some of the bits in the cert >>>> 2) find some other way to define the other bits we need to sign. >>>=20 >>> More or less, yes, I think so. However I'd describe it as: >>>=20 >>> 1) Only include elements that controllers of a zone should be able = to assert in the RR (key text, some usage requirements) >>> 2) Put everything else in a cert signed by a third-party that has = authority to assert that stuff >>=20 >> This is significantly inferior: >>=20 >> a) It requires that domain authorities now understand the semantics = of the certificates rather than just treating them as opaque binary = blobs. >=20 > By "domain authorities" you mean the administrator of the zone data? = If so, then yes you are right. >=20 >> b) It requires that all validators understand the semantics of the = certificates rather than just treating them as opaque binary blobs. >=20 > Certainly not all DNSSEC validators (that's what you seem to be = implying below). Only the TLS module needs to be changed to first pull = out the key. The rest of the DNSSEC chain works as normal. Except the model existing for DNSSEC is that an ARBITRARY RR can be = validated by any DNSSEC cache or intermediatry. By only validating a = portion of the data, you break this model for no benefit: such an RR = would be very different from every other resource record in terms of = validation by intermediaries: DNS has the property that any unknown = record type should be treatable as an opaque blob of bits, including for = the purpose of validation. >> c) It prevents the framework from ever accommodating other types of = certificates. >=20 > I don't think this is the case. The framework supports any kind of = certificate that uses public keys, and application developers are free = to develop such certs/protocols (eg. OpenPGP over TLS) without forcing = anyone that wants to use it to put new certs into DNS. I'd be really worried about "validating only part" actually being done = right. That really scares me as well. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F103A6ACF for ; Mon, 23 Aug 2010 12:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PEfa+MmJzBL for ; Mon, 23 Aug 2010 12:43:25 -0700 (PDT) Received: from mail166.messagelabs.com (mail166.messagelabs.com [216.82.253.163]) by core3.amsl.com (Postfix) with SMTP id 82D213A6AB8 for ; Mon, 23 Aug 2010 12:43:25 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-5.tower-166.messagelabs.com!1282592638!37249896!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.6] Received: (qmail 10232 invoked from network); 23 Aug 2010 19:43:58 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.6) by server-5.tower-166.messagelabs.com with SMTP; 23 Aug 2010 19:43:58 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Aug 2010 15:43:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt Thread-Index: ActC9/eoTAMzTEU/TMaEC35EDU4SMwAAkdiw References: <871v9pu5ba.fsf@mocca.josefsson.org><8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu><7C407E48-9E99-44CB-BA31-306C0574E15F@Princeton.EDU> From: "Carl Wallace" To: "Paul Wouters" , "Stephen Schultze" Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:43:26 -0000 > That's right. We no longer trust CA's. That's a feature, not a bug. If the intent is to use the key association match exclusively, state that in the I-D along with security considerations verbiage describing what is gained/lost relative to the status quo. The current draft calls for conventional PKIX validation (nebulous processing rules aside). > Anyone who wants to use CA's, can stick to what's deployed today. Any > new trust > or usage or authorization constraints can be resolved within the X.509 > attribute > space. This need not be either/or. =20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DBA3A6AC0 for ; Mon, 23 Aug 2010 12:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.861, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWABI0wmAyUD for ; Mon, 23 Aug 2010 12:39:26 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id E08DF3A6AC6 for ; Mon, 23 Aug 2010 12:39:25 -0700 (PDT) Received: by gwb20 with SMTP id 20so2701069gwb.31 for ; Mon, 23 Aug 2010 12:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IduxJ601BPIiU4BX8TEtDzZ4Qa9jcUC4Tmtmacou0yw=; b=lREImiL6tOrcuquhh4tFmHXRFXP1dfrbYvYfJqAN7tsyzFJotQ+yH3EtwM9xqgwjGD NlIRg44Ge5g/Kwaac8WngMpSzz5C9Qp/a0BbMvNCO7lING1tdMOoVNrFIlSmbowOHgfN tIBA5gufYQHG86PSAfB2oldpyOpejKMocwWhg= 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:content-transfer-encoding; b=hDWvy0C7l/QyJ7picA1hv2t2oC2WG2bzkvr5AOfIo4b2aC9MRtb+jG6BnT4KbZrPVd Y/2YZ0i2fiwJFueh0QWuHSAOLNDzkW9sU24pbmn0xRTe1w5FW2TwS8RMmpfA46SDU9mY bFi2GszRw4zyQh+6OiEm6NnIadoxMhhFoYVZ8= MIME-Version: 1.0 Received: by 10.90.71.1 with SMTP id t1mr3727174aga.65.1282592398205; Mon, 23 Aug 2010 12:39:58 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Mon, 23 Aug 2010 12:39:58 -0700 (PDT) In-Reply-To: <850D9F1E-094F-4FA4-9B2D-445C1844A14D@bbn.com> References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <850D9F1E-094F-4FA4-9B2D-445C1844A14D@bbn.com> Date: Mon, 23 Aug 2010 15:39:58 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:39:30 -0000 On Mon, Aug 23, 2010 at 3:00 PM, Richard L. Barnes wrote: >> That is close but I don't think we can reuse the CERT record and then >> put policy information in it such as 'SSL required'. >> >> That should be separated out into another record. Otherwise we end up >> treating CERT in the same manner as TXT has been (ab)used. > > Definitely agree with not using CERT for that sort of policy information, > but I would go further to say that policy isn't the domain of this group. > =A0The definition of "SSL required" will vary quite a bit between > applications, so policy work is more appropriately done in more > application-specific groups, such as the proposed HASMAT group for HTTP: > Group? What Group? You seem to be assuming that the outcome of this process is a group that works out how to use DNSSEC to secure abstract applications. If that type of work is practical, I would say it should be done in DNSEXT. I think the rather more likely outcome of this group is a WG that has a scope limited to one specific application but is told to go and do it in a general way. For example, work out how to make HTTP over SSL work in this framework. Unless we make some very precise statements about applications, I can't see us getting the application writers involved. And without the involvement of people who write code people use a WG means nothing. -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D98E3A6ACA for ; Mon, 23 Aug 2010 12:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.155 X-Spam-Level: X-Spam-Status: No, score=-4.155 tagged_above=-999 required=5 tests=[AWL=-1.556, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StmN3A9ZFJQw for ; Mon, 23 Aug 2010 12:34:05 -0700 (PDT) Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id 038BD3A6AC6 for ; Mon, 23 Aug 2010 12:34:04 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7NJYc90023243 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Aug 2010 15:34:38 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7NJYb5F007285 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 15:34:37 -0400 (EDT) Message-Id: From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 15:34:37 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <7C407E48-9E99-44CB-BA31-306C0574E15F@Princeton.EDU> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6083 signatures=637993 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008230156 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:34:06 -0000 On Aug 23, 2010, at 3:18 PM, Paul Wouters wrote: > On Mon, 23 Aug 2010, Stephen Schultze wrote: > >> To the extent that there are constraints or other features that >> currently appear in X.509 or other cert standards that can be >> authoritatively asserted by the person who controls a zone, those >> should be made part of the RR. > > Data authorisation duplication is an extremely bad idea. Multiple > authorities > could give different answers and then what do you end up doing? > Again, it > makes no sense to reproduce X.509 in DNS and then use out-of-bounds CA > validation requirements. This is going to be an issue regardless of the decision on this issue. What do you do if you have an expired or revoked certificate/ key that nevertheless has a valid hash in DNS? The real problem is that if you do not explicitly separate the DNS answer and the certificate answer, especially if the cert is signed by a third party, it is not clear who is asserting the answer. Sure, you could pick out which X.509 fields are considered asserted by a DNS answer if the hash is present (and perhaps this is what people will want to do) but that is no better than explicitly separating them with respect to your critique. >> And I think that giving controllers of zones the ability to assert >> things that only CAs used to be able to assert would be a changed >> security assumption. > > That's right. We no longer trust CA's. That's a feature, not a bug. Agreed, but it is a bug if somehow we end up allowing controllers of zones to make and have validated assertions for things that they shouldn't be trusted for, or if we create ambiguity about who is asserting what. As such, if we end up cherry-picking fields from X. 509 we need to specify clearly what it means in this regard. In any case, my point was obviously that in either scenario we are presuming a changed security assumption, which was Phillip's objection. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28A593A6AC3 for ; Mon, 23 Aug 2010 12:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wM0MR06tgP+a for ; Mon, 23 Aug 2010 12:21:21 -0700 (PDT) Received: from ppa02.Princeton.EDU (ppa02.Princeton.EDU [128.112.128.216]) by core3.amsl.com (Postfix) with ESMTP id 4F9003A6AA3 for ; Mon, 23 Aug 2010 12:21:21 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa02.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7NJLsGG022061 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Aug 2010 15:21:54 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7NJLr5F002023 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 15:21:54 -0400 (EDT) Message-Id: <64D01BFB-8CCC-4884-9124-1ED70E7EF924@Princeton.EDU> From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: <5E5BB1D2-B6B0-4632-B6F7-51244FDDE5A7@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 15:21:53 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <5E5BB1D2-B6B0-4632-B6F7-51244FDDE5A7@icsi.berkeley.edu> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6083 signatures=637993 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008230152 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:21:23 -0000 On Aug 23, 2010, at 2:58 PM, Nicholas Weaver wrote: > On Aug 23, 2010, at 11:51 AM, Stephen Schultze wrote: >> On Aug 23, 2010, at 1:18 PM, Phillip Hallam-Baker wrote: >>>> The DNS location can show the permitted use. DNSSEC can provide the >>>> validation for that. >>> >>> So now your proposal is >>> >>> 1) Only sign some of the bits in the cert >>> 2) find some other way to define the other bits we need to sign. >> >> More or less, yes, I think so. However I'd describe it as: >> >> 1) Only include elements that controllers of a zone should be able >> to assert in the RR (key text, some usage requirements) >> 2) Put everything else in a cert signed by a third-party that has >> authority to assert that stuff > > This is significantly inferior: > > a) It requires that domain authorities now understand the semantics > of the certificates rather than just treating them as opaque binary > blobs. By "domain authorities" you mean the administrator of the zone data? If so, then yes you are right. > b) It requires that all validators understand the semantics of the > certificates rather than just treating them as opaque binary blobs. Certainly not all DNSSEC validators (that's what you seem to be implying below). Only the TLS module needs to be changed to first pull out the key. The rest of the DNSSEC chain works as normal. > c) It prevents the framework from ever accommodating other types of > certificates. I don't think this is the case. The framework supports any kind of certificate that uses public keys, and application developers are free to develop such certs/protocols (eg. OpenPGP over TLS) without forcing anyone that wants to use it to put new certs into DNS. > B is especially bad: Although I argue that DNSSEC validation on the > not-end-host caches is a bad idea, people want to do it. A new > record type MUST NOT require a new validation algorithm that only > covers portions of the data, rather it MUST use the existing defined > mechanism of 'an unknown record is simply opaque data'. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51DF23A6A8D for ; Mon, 23 Aug 2010 12:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwzoV8z+ndTw for ; Mon, 23 Aug 2010 12:17:43 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 2C10D3A693F for ; Mon, 23 Aug 2010 12:17:43 -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 5783DC17D; Mon, 23 Aug 2010 15:18:15 -0400 (EDT) Date: Mon, 23 Aug 2010 15:18:15 -0400 (EDT) From: Paul Wouters To: Stephen Schultze In-Reply-To: <7C407E48-9E99-44CB-BA31-306C0574E15F@Princeton.EDU> Message-ID: References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> <7C407E48-9E99-44CB-BA31-306C0574E15F@Princeton.EDU> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:17:44 -0000 On Mon, 23 Aug 2010, Stephen Schultze wrote: > To the extent that there are constraints or other features that currently > appear in X.509 or other cert standards that can be authoritatively asserted > by the person who controls a zone, those should be made part of the RR. Data authorisation duplication is an extremely bad idea. Multiple authorities could give different answers and then what do you end up doing? Again, it makes no sense to reproduce X.509 in DNS and then use out-of-bounds CA validation requirements. > And I think that giving controllers of zones the ability to assert things > that only CAs used to be able to assert would be a changed security > assumption. That's right. We no longer trust CA's. That's a feature, not a bug. Anyone who wants to use CA's, can stick to what's deployed today. Any new trust or usage or authorization constraints can be resolved within the X.509 attribute space. I feel like I'm time travelling into the past. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A410B3A6AC1 for ; Mon, 23 Aug 2010 12:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72xPFi1qqC5Y for ; Mon, 23 Aug 2010 12:15:19 -0700 (PDT) Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id A1C873A6ACB for ; Mon, 23 Aug 2010 12:15:18 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7NJFpM3006799 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Aug 2010 15:15:51 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7NJFppF003821 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 15:15:51 -0400 (EDT) Message-Id: <25DC9C15-669A-4ABD-A5B3-570C11FB5557@Princeton.EDU> From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 15:15:51 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6083 signatures=637993 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008230149 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:15:24 -0000 On Aug 23, 2010, at 2:42 PM, Phillip Hallam-Baker wrote: >> Combining your approach with an >> approach that simply seeks to enable validated domain-to-key >> mapping based >> on the properties of DNSSEC itself has the following disadvantages: >> >> 1. mixing together assertions that require different authority >> 2. locking in applications to either implementing the cert format you >> choose, or adding duplicative cert hash DNS entries for each new >> cert format > > Actually, this appears to me to be the disadvantage of requiring the > DNS systems to pull out the key from the cert. Can you explain? I'm not grokking. >>> the reason we are using certs and not just keys is because we need >>> those additional bits. >> >> I think that the additional bits needed for fully featured >> operation of >> domain-to-key mapping (eg: "require SSL") can be easily built into >> the spec, >> whereas bits that assert other things can still ride in the cert >> itself and >> be validated by whoever signs the cert (if anyone). > > Logically speaking, you need to know about 'require SSL' before you > start processing the certificate that was presented in the SSL > transaction. Is the same not true for knowing whether the cert (or key) you were presented with hashes to what's in DNS? If so, the blocking is the same. You have to wait until you get the RR. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5BE43A6A95 for ; Mon, 23 Aug 2010 12:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3c1gQEkFd36 for ; Mon, 23 Aug 2010 12:07:01 -0700 (PDT) Received: from ppa02.Princeton.EDU (ppa02.Princeton.EDU [128.112.128.216]) by core3.amsl.com (Postfix) with ESMTP id 3E3C73A6ABD for ; Mon, 23 Aug 2010 12:05:40 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa02.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7NJ6DCH007938 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Aug 2010 15:06:13 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7NJ6DpF029018 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 15:06:13 -0400 (EDT) Message-Id: <42F35F7C-5C91-4D6A-BFDE-4E0EF052591C@Princeton.EDU> From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEAE4694A4A@DEN-MEXMS-001.corp.ebay.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 15:06:13 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> <5EE049BA3C6538409BBE6F1760F328ABEAE4694A4A@DEN-MEXMS-001.corp.ebay.com> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6083 signatures=637993 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008230147 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 19:07:03 -0000 explicit: - hash algorithm - "use SSL" - other handshake-related variables like secure renegotiation implied: - domain constraints within the zone in question - expiration (TTL) - pathLenConstraint=0 (I think this makes sense in order to limit DNSSEC key assurance to leaf nodes only) On Aug 23, 2010, at 2:54 PM, Steingruebl, Andy wrote: >> -----Original Message----- >> From: keyassure-bounces@ietf.org [mailto:keyassure- >> bounces@ietf.org] On Behalf Of Stephen Schultze >> >> Certification of which bits? All of the bits in the cert, or only >> those that >> you've decided are allowed? >> >> I do think that I now better understand what you are proposing. >> Correct me if I'm wrong. You want the ability for whoever controls >> a zone to >> hash certs and place them in DNS (essentially signing them) so that >> they can >> make any manner of assertions. This turns them into their own >> little CA for >> their own domain. > > I think it would help me if we could put together a list of types of > certificates and assertions that currently aren't conveyed via DNS > but that we are proposing can be conveyed that way. And, which of > those that aren't currently conveyed via DNS implicitly rely somehow > on DNS in their lifecycle. > > As Warren has pointed out quite well in previous emails and Dan > Kaminsky has pointed out elsewhere, we're relying on DNS security > and whoever controls a zone for a huge portion of the trust already, > even if we don't realize it. In those cases we're already trusting > whoever administers DNS, we just haven't listed them in our trust > model. > > In those cases since we already have to extend trust to them, we > might as well make it explicit and put all of that data into DNS. It > solves more problems than it causes. > > Should code-signing keys be in DNS, maybe not. But it depends on > how they are currently issued I suppose. If the current trust chain > goes through DNS, then we either remove that dependency or > explicitly embrace it. > > I would like to see an enumeration of the keys/certs we're > discussing, use-cases, etc. Phillip laid out several criteria here: http://www.ietf.org/mail-archive/web/keyassure/current/msg00177.html > but I think we can flesh this out a little with explicitly listing > what types of certs we will consider and which ones we won't. > > - Andy > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2682C3A6A95 for ; Mon, 23 Aug 2010 11:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPGNxNtCrFcT for ; Mon, 23 Aug 2010 11:59:57 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 51E883A6A8D for ; Mon, 23 Aug 2010 11:59:56 -0700 (PDT) Received: from ros-dhcp192-1-51-64.bbn.com ([192.1.51.64]:54072) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OncFx-000EUx-Ca; Mon, 23 Aug 2010 15:00:29 -0400 Message-Id: <850D9F1E-094F-4FA4-9B2D-445C1844A14D@bbn.com> From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 15:00:28 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 18:59:59 -0000 > That is close but I don't think we can reuse the CERT record and then > put policy information in it such as 'SSL required'. > > That should be separated out into another record. Otherwise we end up > treating CERT in the same manner as TXT has been (ab)used. Definitely agree with not using CERT for that sort of policy information, but I would go further to say that policy isn't the domain of this group. The definition of "SSL required" will vary quite a bit between applications, so policy work is more appropriately done in more application-specific groups, such as the proposed HASMAT group for HTTP: --Richard >> I suppose this is an interesting use case, but it would require >> additional >> client infrastructure to build in trust bits for individual zones. >> Furthermore, I'm not sure why you wouldn't just use the CERT RR as- >> is, or >> even add a CERTHASH cert type to CERT. Combining your approach >> with an >> approach that simply seeks to enable validated domain-to-key >> mapping based >> on the properties of DNSSEC itself has the following disadvantages: >> >> 1. mixing together assertions that require different authority >> 2. locking in applications to either implementing the cert format you >> choose, or adding duplicative cert hash DNS entries for each new >> cert format > > Actually, this appears to me to be the disadvantage of requiring the > DNS systems to pull out the key from the cert. > > I really don't have a problem with a draft that says 'here is how you > validate a trust chain in which portions of the chain are in DNSSEC > and here is the conclusions that you may draw'. We give that advice to > relying parties all the time. > > There is going to be a list of caveats on these trust chains that is > going to be impressively long no matter what. > > >>> the reason we are using certs and not just keys is because we need >>> those additional bits. >> >> I think that the additional bits needed for fully featured >> operation of >> domain-to-key mapping (eg: "require SSL") can be easily built into >> the spec, >> whereas bits that assert other things can still ride in the cert >> itself and >> be validated by whoever signs the cert (if anyone). > > Logically speaking, you need to know about 'require SSL' before you > start processing the certificate that was presented in the SSL > transaction. > > >> >> On Aug 23, 2010, at 11:38 AM, Phillip Hallam-Baker wrote: >>> >>> The idea of limiting the authentication to the key seems to be >>> because >>> people are worried that people 'might do the wrong thing' with it. >>> >>> My experience is that this is a futile approach. If people are going >>> to do the wrong thing with the subject field they are going to do >>> that >>> whether or not it is authenticated by the CERT hash. >>> >>> The only way to ensure that people use nothing but the key is to put >>> nothing but the key in the record (which we can do already). >>> >>> >>> What we are trying to do here is to change the semantics of the CERT >>> record so the act of publishing one in the DNS becomes in effect a >>> CA >>> certification of those bits. That is a validation path in its own >>> right. >>> >>> For example, I might have a device that ships with a device >>> certificate. I want to use the device in my network. So I pull the >>> cert from the device, take the hash and put the hash into my DNS, >>> thus >>> declaring that this is a device I authorize for use with my DNS >>> zone. >>> >>> The device cert is CA issued and asserts a particular function. I am >>> only going to put the cert in my DNS if I endorse that function. >>> >>> the reason we are using certs and not just keys is because we need >>> those additional bits. >>> >>> Incidentally, one of the reasons we might want a new record is >>> precisely because we are changing the semantics of CERT, even if >>> what >>> we are doing here is to give it the semantics it should have had in >>> the first place. >>> >>> On Mon, Aug 23, 2010 at 11:20 AM, Steve Schultze >>> wrote: >>>> >>>> On Aug 23, 2010, at 11:01 AM, Phillip Hallam-Baker wrote: >>>>> >>>>> Given the choice between giving people with brains the information >>>>> they need to do the job right and not giving the information in >>>>> case >>>>> it is misused by cretins, I suggest taking the first approach. >>>> >>>> I'm having trouble figuring out who the cretins vs the people >>>> with brains >>>> are in your scenario, but fortunately it doesn't matter if we >>>> design a >>>> system in which people can assert only what they are trusted to >>>> assert. >>>> >>>> If your concern is... >>>>> >>>>> SSL use can be controlled by key use bits and extensions in the >>>>> cert. >>>> >>>> Then the answer is twofold: >>>> 1. these bits can continue to be used, and will be trusted if the >>>> CA is >>>> trusted >>>> 2. if you wish to enforce this in the absence of a CA-trusted >>>> cert, we >>>> can include an option in the RR standard for requiring SSL (which >>>> is an >>>> assertion that the zone controller can be trusted to make) >> >> >> >> >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >> > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43D023A68A7 for ; Mon, 23 Aug 2010 11:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.695, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXSZ0iSSYxBJ for ; Mon, 23 Aug 2010 11:57:35 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 4DA4C3A693E for ; Mon, 23 Aug 2010 11:57:35 -0700 (PDT) Received: by qyk1 with SMTP id 1so2939672qyk.10 for ; Mon, 23 Aug 2010 11:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=9p2NZpTSdUgGQpJesqg6KPVnYC45Hb9JS2PTkTSKaBE=; b=SFqE3qWoBbYQA2zMBylzYt+snitBnrvaHGdDZuSY7UT96i5F5f7l9RFPrCafocbm+n ljUFlnYVhoxE6wxcvyEm7VckF3oGRspP5GXVOLuPpIEBmTnB2wAQovoSxSg8hBOKDPZL JpDm8Hg7a9Y4OJeamZ5vsODV0mTU8hkutH7bc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=kARGANKeVDNsVxdlwSk14ki8aHJW1VmhblP5+21OFYPMV9qQc9RA85WpIFXkImx1xG ehnDoDhULfWEkgH4WW6RPACUBdVknkVdARk5o/vCE4vtMpSwz2p8+KPQy9VCuJv6uUyK 8INRSDW7PNhIAjxZk8sXAsemDYv3nulYpfka8= Received: by 10.224.114.81 with SMTP id d17mr3601562qaq.380.1282589887327; Mon, 23 Aug 2010 11:58:07 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id f15sm7391238qcr.37.2010.08.23.11.58.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Aug 2010 11:58:06 -0700 (PDT) Sender: Nicholas Weaver References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <5E5BB1D2-B6B0-4632-B6F7-51244FDDE5A7@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Mon, 23 Aug 2010 11:58:03 -0700 To: Stephen Schultze X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 18:57:36 -0000 On Aug 23, 2010, at 11:51 AM, Stephen Schultze wrote: > On Aug 23, 2010, at 1:18 PM, Phillip Hallam-Baker wrote: >>> The DNS location can show the permitted use. DNSSEC can provide the >>> validation for that. >>=20 >> So now your proposal is >>=20 >> 1) Only sign some of the bits in the cert >> 2) find some other way to define the other bits we need to sign. >=20 > More or less, yes, I think so. However I'd describe it as: >=20 > 1) Only include elements that controllers of a zone should be able to = assert in the RR (key text, some usage requirements) > 2) Put everything else in a cert signed by a third-party that has = authority to assert that stuff This is significantly inferior: a) It requires that domain authorities now understand the semantics of = the certificates rather than just treating them as opaque binary blobs. b) It requires that all validators understand the semantics of the = certificates rather than just treating them as opaque binary blobs. c) It prevents the framework from ever accommodating other types of = certificates. B is especially bad: Although I argue that DNSSEC validation on the = not-end-host caches is a bad idea, people want to do it. A new record = type MUST NOT require a new validation algorithm that only covers = portions of the data, rather it MUST use the existing defined mechanism = of 'an unknown record is simply opaque data'. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F243A6A9D for ; Mon, 23 Aug 2010 11:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.117 X-Spam-Level: X-Spam-Status: No, score=-5.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlAqrZLrPXmF for ; Mon, 23 Aug 2010 11:54:06 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id F28E33A69D4 for ; Mon, 23 Aug 2010 11:54:05 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=uTYVOwqs2sjjLaQjJ3NTJYrIhF7OK1Zt4HA4GHwu4coE9mFNmfML1bLd sJ4WjNA8qauCFPkHzoAuJPml9Ao/QxES3jUVQCR7k4aZfmB/Gq8tvu8fb katuHai4s6vOpy4; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1282589679; x=1314125679; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Stephen=20Schultze=20,=20" keyassure@ietf.org"=0D=0A=09|Date:=20 Mon,=2023=20Aug=202010=2012:54:38=20-0600|Subject:=20RE: =20[keyassure]=20Introducing=20draft-josefsson-keyassure- tls-00.txt|Message-ID:=20<5EE049BA3C6538409BBE6F1760F328A BEAE4694A4A@DEN-MEXMS-001.corp.ebay.com>|References:=20<8 71v9pu5ba.fsf@mocca.josefsson.org>=0D=0A=09=0D=0A=09=0D=0A=09<781622DC- 8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU>=0D=0A=09=0D=0A=09<7C571132-83C8-4488-9256-694B2F7BC15A@Princeton .EDU>=0D=0A=09=0D=0A=20<092DDC4B-DB65-4150-867D-EC89 93EEFF9B@Princeton.EDU>|In-Reply-To:=20<092DDC4B-DB65-415 0-867D-EC8993EEFF9B@Princeton.EDU> |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=uC10TR2M5ELtu60odtg40joouk102Mp0/QK9WDeDZTI=; b=jfskmMlXzaTfUIkmzkZqtaBDBvc2ZmxUxVyuW/H/PdrNbWtE1FwgAS8c aMwM3CchkWnBxFbAXcVTEBGrp9rM+0U0K6GTOmonZPeWiV4y0a/p6oUVc w32sTcCnEChMKPk; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.56,259,1280732400"; d="scan'208";a="71912779" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 23 Aug 2010 11:54:39 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.228]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Mon, 23 Aug 2010 12:54:38 -0600 From: "Steingruebl, Andy" To: Stephen Schultze , "keyassure@ietf.org" Date: Mon, 23 Aug 2010 12:54:38 -0600 Thread-Topic: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt Thread-Index: ActC8E79J17mKC8zRnGQbnwPjpu+2gAA21Kw Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEAE4694A4A@DEN-MEXMS-001.corp.ebay.com> References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> In-Reply-To: <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 18:54:07 -0000 > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On B= ehalf Of Stephen Schultze >=20 > Certification of which bits? All of the bits in the cert, or only those = that > you've decided are allowed? >=20 > I do think that I now better understand what you are proposing. > Correct me if I'm wrong. You want the ability for whoever controls a zon= e to > hash certs and place them in DNS (essentially signing them) so that they = can > make any manner of assertions. This turns them into their own little CA = for > their own domain. =20 I think it would help me if we could put together a list of types of certif= icates and assertions that currently aren't conveyed via DNS but that we ar= e proposing can be conveyed that way. And, which of those that aren't curr= ently conveyed via DNS implicitly rely somehow on DNS in their lifecycle. = =20 As Warren has pointed out quite well in previous emails and Dan Kaminsky ha= s pointed out elsewhere, we're relying on DNS security and whoever controls= a zone for a huge portion of the trust already, even if we don't realize i= t. In those cases we're already trusting whoever administers DNS, we just = haven't listed them in our trust model. In those cases since we already have to extend trust to them, we might as w= ell make it explicit and put all of that data into DNS. It solves more prob= lems than it causes. Should code-signing keys be in DNS, maybe not. But it depends on how they = are currently issued I suppose. If the current trust chain goes through DNS= , then we either remove that dependency or explicitly embrace it. I would like to see an enumeration of the keys/certs we're discussing, use-= cases, etc. Phillip laid out several criteria here: http://www.ietf.org/mai= l-archive/web/keyassure/current/msg00177.html but I think we can flesh this= out a little with explicitly listing what types of certs we will consider = and which ones we won't. - Andy Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC58F3A6A9D for ; Mon, 23 Aug 2010 11:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI-ofTxLEyg1 for ; Mon, 23 Aug 2010 11:51:01 -0700 (PDT) Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id AE62D3A6A99 for ; Mon, 23 Aug 2010 11:51:01 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7NIpYQj016499 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Aug 2010 14:51:34 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7NIpYpF022215 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 14:51:34 -0400 (EDT) Message-Id: From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 14:51:34 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6083 signatures=637993 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008230141 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 18:51:03 -0000 On Aug 23, 2010, at 1:18 PM, Phillip Hallam-Baker wrote: >> The DNS location can show the permitted use. DNSSEC can provide the >> validation for that. > > So now your proposal is > > 1) Only sign some of the bits in the cert > 2) find some other way to define the other bits we need to sign. More or less, yes, I think so. However I'd describe it as: 1) Only include elements that controllers of a zone should be able to assert in the RR (key text, some usage requirements) 2) Put everything else in a cert signed by a third-party that has authority to assert that stuff Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE113A6A99 for ; Mon, 23 Aug 2010 11:47:48 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQrNHvBMZPTl for ; Mon, 23 Aug 2010 11:47:47 -0700 (PDT) Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id 377AA3A6A7F for ; Mon, 23 Aug 2010 11:47:47 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id o7NImK33014776 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Aug 2010 14:48:20 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7NImJ5F016280 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 14:48:19 -0400 (EDT) Message-Id: <7C407E48-9E99-44CB-BA31-306C0574E15F@Princeton.EDU> From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 14:48:19 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6083 signatures=637993 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008230141 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 18:47:48 -0000 On Aug 23, 2010, at 12:41 PM, Phillip Hallam-Baker wrote: > Why not have the DNSSEC module check the hash against the full > certificate? > > That way the TLS module does not even need to know it is using DNSSEC > key assurance? If it does not know it is using DNSSEC key assurance, then it can't validate _anything_ without getting a third party involved. > There are two types of information in a certificate besides the key: > > 1) Assertions concerning properties of the certificate subject > 2) Assertions concerning the permitted uses of the key. > > Whatever you think about the desirability of authenticating the first. Desirable, but not able to be authenticated via DNSSEC key assurance. > You will break SSL if you do not authenticate the second set of > information. Any assertions concerning the permitted uses of the key that the controller of a zone should be authorized to make could be represented in the RR. Any uses that they are not authorized to make should not be respected unless there is some third-party validation. Unless you can give a more concrete example of how you think this breaks SSL I'm not sure how to answer. > The reason that I do not want to modify SSL to use raw keys is that it > was built on an assumption that the second type of information would > be authenticated and assured. To the extent that there are constraints or other features that currently appear in X.509 or other cert standards that can be authoritatively asserted by the person who controls a zone, those should be made part of the RR. At that point it's not a "raw key." You're right, though, that to date that a DNSSEC-secured domain-based approach has not been a mode of operation for SSL. In any case, the SSL handshake stays the same, and it can be an X.509- based handshake or OpenPGP-via-TLS or whatever other standard might exist. The only difference is that the domain-to-key mapping portion of validation on the client, but this is work that has to be done regardless of whether you hash the whole cert or just the key. > Changing the security assumptions on which an existing protocol is > built is the most common way of breaking them. And I think that giving controllers of zones the ability to assert things that only CAs used to be able to assert would be a changed security assumption. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EADAC3A6A75 for ; Mon, 23 Aug 2010 11:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[AWL=0.968, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAojF3n5tRe1 for ; Mon, 23 Aug 2010 11:42:01 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 18DC23A6A70 for ; Mon, 23 Aug 2010 11:42:00 -0700 (PDT) Received: by gwb20 with SMTP id 20so2665366gwb.31 for ; Mon, 23 Aug 2010 11:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dvFFAdDQAd9UrledIj6qPifHVfgUzwWY9dGw0RkW8Gs=; b=Sls45EXm5tO0oAFMFIh5i+lht9yQHQ29uFsR7AUH6P99UOQF9WxTWoE5XW+Aec8zBN ASgP5UvJ4X+GnhX2JRZ3h8HLdY5Spg1fYjnb1vgAxCD+IuJUbkAsMObB7Bc4FW2I4Jc/ qnk4iypbf33qNAnl4EuRcgd3GrguqiVjW7k9M= 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:content-transfer-encoding; b=VPcaSgDAnJpFn6q8F1STlYJ4xwhO6PtF4vabWXZ4YJcq+uzOtisQzdefwsqpCqkS7J BJwuX1K3s2iD2yHUh/1r6IYojJdxaeN80CTeJh4WR6qY4BadFlUPux9ZPYjXuNkY6QDU Ue4MWuiwhLC9SgAN1dcQUxWeH0FhlhisPUBPg= MIME-Version: 1.0 Received: by 10.151.78.6 with SMTP id f6mr5408413ybl.240.1282588954171; Mon, 23 Aug 2010 11:42:34 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Mon, 23 Aug 2010 11:42:34 -0700 (PDT) In-Reply-To: <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> Date: Mon, 23 Aug 2010 14:42:34 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Schultze Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 18:42:03 -0000 On Mon, Aug 23, 2010 at 2:23 PM, Stephen Schultze wrote= : > I do think that I now better understand what you are proposing. =A0Correc= t me > if I'm wrong. =A0You want the ability for whoever controls a zone to hash > certs and place them in DNS (essentially signing them) so that they can m= ake > any manner of assertions. =A0This turns them into their own little CA for > their own domain. =A0You would define some subset of assertions that are > trusted by default as long as they come from a signed record =A0(so far I= 've > seen "text of public key" and "SSL required"). =A0However, other assertio= ns > might become trusted if the end user decides to trust the controller of t= he > zone to a greater degree (a degree not justified merely by the fact that > they are the controller of the zone). =A0One way of obtaining this greate= r > degree of trust might be for a certificate to be signed by a trusted > third-party (like today's CAs), but evidently you envision some other > validation path from the signed zone to a trusted root. That is close but I don't think we can reuse the CERT record and then put policy information in it such as 'SSL required'. That should be separated out into another record. Otherwise we end up treating CERT in the same manner as TXT has been (ab)used. > I suppose this is an interesting use case, but it would require additiona= l > client infrastructure to build in trust bits for individual zones. > =A0Furthermore, I'm not sure why you wouldn't just use the CERT RR as-is,= or > even add a CERTHASH cert type to CERT. =A0Combining your approach with an > approach that simply seeks to enable validated domain-to-key mapping base= d > on the properties of DNSSEC itself has the following disadvantages: > > 1. mixing together assertions that require different authority > 2. locking in applications to either implementing the cert format you > choose, or adding duplicative cert hash DNS entries for each new cert for= mat Actually, this appears to me to be the disadvantage of requiring the DNS systems to pull out the key from the cert. I really don't have a problem with a draft that says 'here is how you validate a trust chain in which portions of the chain are in DNSSEC and here is the conclusions that you may draw'. We give that advice to relying parties all the time. There is going to be a list of caveats on these trust chains that is going to be impressively long no matter what. >> the reason we are using certs and not just keys is because we need >> those additional bits. > > I think that the additional bits needed for fully featured operation of > domain-to-key mapping (eg: "require SSL") can be easily built into the sp= ec, > whereas bits that assert other things can still ride in the cert itself a= nd > be validated by whoever signs the cert (if anyone). Logically speaking, you need to know about 'require SSL' before you start processing the certificate that was presented in the SSL transaction. > > On Aug 23, 2010, at 11:38 AM, Phillip Hallam-Baker wrote: >> >> The idea of limiting the authentication to the key seems to be because >> people are worried that people 'might do the wrong thing' with it. >> >> My experience is that this is a futile approach. If people are going >> to do the wrong thing with the subject field they are going to do that >> whether or not it is authenticated by the CERT hash. >> >> The only way to ensure that people use nothing but the key is to put >> nothing but the key in the record (which we can do already). >> >> >> What we are trying to do here is to change the semantics of the CERT >> record so the act of publishing one in the DNS becomes in effect a CA >> certification of those bits. That is a validation path in its own >> right. >> >> For example, I might have a device that ships with a device >> certificate. I want to use the device in my network. So I pull the >> cert from the device, take the hash and put the hash into my DNS, thus >> declaring that this is a device I authorize for use with my DNS zone. >> >> The device cert is CA issued and asserts a particular function. I am >> only going to put the cert in my DNS if I endorse that function. >> >> the reason we are using certs and not just keys is because we need >> those additional bits. >> >> Incidentally, one of the reasons we might want a new record is >> precisely because we are changing the semantics of CERT, even if what >> we are doing here is to give it the semantics it should have had in >> the first place. >> >> On Mon, Aug 23, 2010 at 11:20 AM, Steve Schultze >> wrote: >>> >>> On Aug 23, 2010, at 11:01 AM, Phillip Hallam-Baker wrote: >>>> >>>> Given the choice between giving people with brains the information >>>> they need to do the job right and not giving the information in case >>>> it is misused by cretins, I suggest taking the first approach. >>> >>> I'm having trouble figuring out who the cretins vs the people with brai= ns >>> are in your scenario, but fortunately it doesn't matter if we design a >>> system in which people can assert only what they are trusted to assert. >>> >>> If your concern is... >>>> >>>> SSL use can be controlled by key use bits and extensions in the cert. >>> >>> Then the answer is twofold: >>> 1. these bits can continue to be used, and will be trusted if the CA is >>> trusted >>> 2. if you wish to enforce this in the absence of a CA-trusted cert, we >>> can include an option in the RR standard for requiring SSL (which is an >>> assertion that the zone controller can be trusted to make) > > > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063C43A6A65 for ; Mon, 23 Aug 2010 11:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uglSgs+IrelW for ; Mon, 23 Aug 2010 11:22:59 -0700 (PDT) Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id A56A63A6889 for ; Mon, 23 Aug 2010 11:22:59 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7NINWid018064 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Aug 2010 14:23:32 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7NINW5F005042 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 14:23:32 -0400 (EDT) Message-Id: <092DDC4B-DB65-4150-867D-EC8993EEFF9B@Princeton.EDU> From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 14:23:31 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6083 signatures=637993 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008230137 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 18:23:01 -0000 Phillip accidentally sent his response only to me. His full message is at the bottom, but my in-lines are below. On Aug 23, 2010, at 11:38 AM, Phillip Hallam-Baker wrote: > The idea of limiting the authentication to the key seems to be because > people are worried that people 'might do the wrong thing' with it. I think the idea is that hashing the entire cert indicates that the controller of the zone asserts that everything contained in the cert is accurate, which is something that they alone do not have the authority to do. The only way to avoid this would be a to create a whitelist of cert properties that are to be trusted purely based on receiving a DNSSEC-validated answer. > The only way to ensure that people use nothing but the key is to put > nothing but the key in the record (which we can do already). I'm confused, how is it possible already to "put nothing but the key in the record"? > What we are trying to do here is to change the semantics of the CERT > record so the act of publishing one in the DNS becomes in effect a CA > certification of those bits. That is a validation path in its own > right. Certification of which bits? All of the bits in the cert, or only those that you've decided are allowed? I do think that I now better understand what you are proposing. Correct me if I'm wrong. You want the ability for whoever controls a zone to hash certs and place them in DNS (essentially signing them) so that they can make any manner of assertions. This turns them into their own little CA for their own domain. You would define some subset of assertions that are trusted by default as long as they come from a signed record (so far I've seen "text of public key" and "SSL required"). However, other assertions might become trusted if the end user decides to trust the controller of the zone to a greater degree (a degree not justified merely by the fact that they are the controller of the zone). One way of obtaining this greater degree of trust might be for a certificate to be signed by a trusted third-party (like today's CAs), but evidently you envision some other validation path from the signed zone to a trusted root. I suppose this is an interesting use case, but it would require additional client infrastructure to build in trust bits for individual zones. Furthermore, I'm not sure why you wouldn't just use the CERT RR as-is, or even add a CERTHASH cert type to CERT. Combining your approach with an approach that simply seeks to enable validated domain- to-key mapping based on the properties of DNSSEC itself has the following disadvantages: 1. mixing together assertions that require different authority 2. locking in applications to either implementing the cert format you choose, or adding duplicative cert hash DNS entries for each new cert format > the reason we are using certs and not just keys is because we need > those additional bits. I think that the additional bits needed for fully featured operation of domain-to-key mapping (eg: "require SSL") can be easily built into the spec, whereas bits that assert other things can still ride in the cert itself and be validated by whoever signs the cert (if anyone). On Aug 23, 2010, at 11:38 AM, Phillip Hallam-Baker wrote: > The idea of limiting the authentication to the key seems to be because > people are worried that people 'might do the wrong thing' with it. > > My experience is that this is a futile approach. If people are going > to do the wrong thing with the subject field they are going to do that > whether or not it is authenticated by the CERT hash. > > The only way to ensure that people use nothing but the key is to put > nothing but the key in the record (which we can do already). > > > What we are trying to do here is to change the semantics of the CERT > record so the act of publishing one in the DNS becomes in effect a CA > certification of those bits. That is a validation path in its own > right. > > For example, I might have a device that ships with a device > certificate. I want to use the device in my network. So I pull the > cert from the device, take the hash and put the hash into my DNS, thus > declaring that this is a device I authorize for use with my DNS zone. > > The device cert is CA issued and asserts a particular function. I am > only going to put the cert in my DNS if I endorse that function. > > the reason we are using certs and not just keys is because we need > those additional bits. > > Incidentally, one of the reasons we might want a new record is > precisely because we are changing the semantics of CERT, even if what > we are doing here is to give it the semantics it should have had in > the first place. > > On Mon, Aug 23, 2010 at 11:20 AM, Steve Schultze > wrote: >> On Aug 23, 2010, at 11:01 AM, Phillip Hallam-Baker wrote: >>> Given the choice between giving people with brains the information >>> they need to do the job right and not giving the information in case >>> it is misused by cretins, I suggest taking the first approach. >> >> I'm having trouble figuring out who the cretins vs the people with >> brains are in your scenario, but fortunately it doesn't matter if >> we design a system in which people can assert only what they are >> trusted to assert. >> >> If your concern is... >>> SSL use can be controlled by key use bits and extensions in the >>> cert. >> >> Then the answer is twofold: >> 1. these bits can continue to be used, and will be trusted if the >> CA is trusted >> 2. if you wish to enforce this in the absence of a CA-trusted cert, >> we can include an option in the RR standard for requiring SSL >> (which is an assertion that the zone controller can be trusted to >> make) Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25353A68F3 for ; Mon, 23 Aug 2010 10:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfPDCN91dVNm for ; Mon, 23 Aug 2010 10:17:31 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 629353A68F6 for ; Mon, 23 Aug 2010 10:17:31 -0700 (PDT) Received: by gxk20 with SMTP id 20so2615441gxk.31 for ; Mon, 23 Aug 2010 10:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2kUARDXQjulGUYv/DllqvLuGLqQYPcr9okT7vytj+Y0=; b=fHB3fiQIq8rT4sCDIGajdfo9YG92/Zvd4EwTo9p20isQZPyUuHpDbTOFvCYKJ7oXnI kbFeREoM0YxaB+86xBPN3DyPxHrAIdoeznJISNl4Dc06BfwgopyUjrJCGpMvc8za/K/p mFWZzv1HImhIhkyKAArfq0IuedRZk5YrDWUuI= 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=LyGEiDS8cXa2oztfJL7q4etbB051vFIafcDcMfqotoRxlbqUIO+6jYgeHhdOpM/0S8 kDuRt/PjmSVTxDNlFdCkYU+iuN+b318xfBYod1Z/5QYdSie3fX8i8RRrXIBxOob1LAsh ucx+7JiCRebja/rVGnVVN1V3FL2cSepkR7uGA= MIME-Version: 1.0 Received: by 10.90.90.20 with SMTP id n20mr3531766agb.165.1282583884018; Mon, 23 Aug 2010 10:18:04 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Mon, 23 Aug 2010 10:18:03 -0700 (PDT) In-Reply-To: References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> Date: Mon, 23 Aug 2010 13:18:03 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 17:17:32 -0000 On Mon, Aug 23, 2010 at 1:02 PM, Paul Wouters wrote: > On Mon, 23 Aug 2010, Phillip Hallam-Baker wrote: > >> There are two types of information in a certificate besides the key: >> >> 1) Assertions concerning properties of the certificate subject >> 2) Assertions concerning the permitted uses of the key. >> >> Whatever you think about the desirability of authenticating the first. >> You will break SSL if you do not authenticate the second set of >> information. >> >> The reason that I do not want to modify SSL to use raw keys is that it >> was built on an assumption that the second type of information would >> be authenticated and assured. > > The DNS location can show the permitted use. DNSSEC can provide the > validation for that. So now your proposal is 1) Only sign some of the bits in the cert 2) find some other way to define the other bits we need to sign. >> Changing the security assumptions on which an existing protocol is >> built is the most common way of breaking them. > > Arguing like that, all X.509 should be removed from DNS and we should all > stick to TXT records. No, this is just another way to validate an X.509 certificate path. Since we already use self-signed certificates, anything that provides more assurance of the chain above the EE cert is useful. >> I see zero advantage to your approach and I see no way that you, I, >> Paul Kocher or anyone else can fully convince themselves that they are >> not breaking SSL in some subtle way. > > SSL currently *is* broken with the 95% self signed certs out there. That > shortcoming is something we're trying to fix - it's too late to prevent it. No, Self-Signed was on the table before SSL v3. We have fifteen years of experience. -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B586D3A68ED for ; Mon, 23 Aug 2010 10:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2kDccvaUMAc for ; Mon, 23 Aug 2010 10:02:25 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id AE5CD3A687E for ; Mon, 23 Aug 2010 10:02:25 -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 BB439C17D; Mon, 23 Aug 2010 13:02:57 -0400 (EDT) Date: Mon, 23 Aug 2010 13:02:57 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 17:02:29 -0000 On Mon, 23 Aug 2010, Phillip Hallam-Baker wrote: > There are two types of information in a certificate besides the key: > > 1) Assertions concerning properties of the certificate subject > 2) Assertions concerning the permitted uses of the key. > > Whatever you think about the desirability of authenticating the first. > You will break SSL if you do not authenticate the second set of > information. > > The reason that I do not want to modify SSL to use raw keys is that it > was built on an assumption that the second type of information would > be authenticated and assured. The DNS location can show the permitted use. DNSSEC can provide the validation for that. > Changing the security assumptions on which an existing protocol is > built is the most common way of breaking them. Arguing like that, all X.509 should be removed from DNS and we should all stick to TXT records. > I see zero advantage to your approach and I see no way that you, I, > Paul Kocher or anyone else can fully convince themselves that they are > not breaking SSL in some subtle way. SSL currently *is* broken with the 95% self signed certs out there. That shortcoming is something we're trying to fix - it's too late to prevent it. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B14D3A68E6 for ; Mon, 23 Aug 2010 09:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20XYCAMySf8K for ; Mon, 23 Aug 2010 09:41:09 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id CFFE63A689C for ; Mon, 23 Aug 2010 09:41:08 -0700 (PDT) Received: by gyg8 with SMTP id 8so2588190gyg.31 for ; Mon, 23 Aug 2010 09:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3ka+jN+EEqx8Jf91JNnM2kbeYnCkJMkZAUZ3gi7dOcE=; b=rrVIypeNc94MYNOmm/nZ089ZT0J4N6bOs8kEjurw7x13+pGGBhgyCoemaKRqmgvTdo yLMl+GnOuuyvgRn89QR0mqzjeQVdA80qcz6x8/JwKudICz4kPHGxpT44NOih4XI8rIXE +N3cH5JazpfmmDd9zM18wZ8t/n5XfCVRjgpFs= 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:content-transfer-encoding; b=NMg+/4sp7srM0BB1BL4mBxNsFwKbJno/Gf16AUpnY2DkuRICYJflfJOfxg3fjXdsN/ apCh2uS0X80m0ap1dfNNu5Hhs/m6gwlVqeeQyxTl1lLR2FQVPlXyL+7eLTmGViZEUoYh 6YW703Y87dqqDQ9V3Tr9BBTomPoVzVGh8coDw= MIME-Version: 1.0 Received: by 10.151.141.1 with SMTP id t1mr2814409ybn.444.1282581702099; Mon, 23 Aug 2010 09:41:42 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Mon, 23 Aug 2010 09:41:41 -0700 (PDT) In-Reply-To: References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> Date: Mon, 23 Aug 2010 12:41:41 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Schultze Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 16:41:10 -0000 Why not have the DNSSEC module check the hash against the full certificate? That way the TLS module does not even need to know it is using DNSSEC key assurance? There are two types of information in a certificate besides the key: 1) Assertions concerning properties of the certificate subject 2) Assertions concerning the permitted uses of the key. Whatever you think about the desirability of authenticating the first. You will break SSL if you do not authenticate the second set of information. The reason that I do not want to modify SSL to use raw keys is that it was built on an assumption that the second type of information would be authenticated and assured. Changing the security assumptions on which an existing protocol is built is the most common way of breaking them. I see zero advantage to your approach and I see no way that you, I, Paul Kocher or anyone else can fully convince themselves that they are not breaking SSL in some subtle way. Take a look at our recent Client cert issue which is a consequence of client certs being supported as an afterthought. On Mon, Aug 23, 2010 at 12:00 PM, Stephen Schultze wrot= e: > On Aug 23, 2010, at 11:19 AM, Nicholas Weaver wrote: >> >> Except that, IMO, there is a huge advantage to be had on simplicity of >> just verifying the ENTIRE certificate. =A0Who says CERT RR's need to be = just >> X.509 format? > > If CERT RR's (or whatever RR we choose) contain public keys, then the > standard supports an arbitrary number of cert formats without creating th= e > need for an additional record every time an application wants a different > type of cert. > >> If the model is the only part validated is the public key in the cert, >> that means that DNS resolver, DNS APIs, and authorities need to be aware= of >> the X.509 format. > > Why is that? =A0Only the application needs to be aware of X.509 (or, in t= he > case of OpenPGP via TLS, an OpenPGP key). =A0Once it gets the key out , i= t > hashes it and checks it against the DNS hierarchy. > >> But if the entire record is just validated as a single binary blob, this >> means that different certificate formats could be used in the future wit= hout >> needing to change anything other than the application which is the final >> consumer of the new certificate type. > > You would be forcing one of two things, either: > a. every application must be updated to use whatever cert standard you ch= ose > b. you =A0must add duplicate entries for each public key for each new cer= t > standard you chose > > Neither seems optimal. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63D1A3A68AF for ; Mon, 23 Aug 2010 08:59:50 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjQegAXPDM2L for ; Mon, 23 Aug 2010 08:59:49 -0700 (PDT) Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id 4A03B3A6817 for ; Mon, 23 Aug 2010 08:59:49 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id o7NG0MNN022357 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Aug 2010 12:00:22 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7NG0L5F028462 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 12:00:22 -0400 (EDT) Message-Id: From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 12:00:21 -0400 References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6082 signatures=637989 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008230106 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 15:59:50 -0000 On Aug 23, 2010, at 11:19 AM, Nicholas Weaver wrote: > Except that, IMO, there is a huge advantage to be had on simplicity > of just verifying the ENTIRE certificate. Who says CERT RR's need > to be just X.509 format? If CERT RR's (or whatever RR we choose) contain public keys, then the standard supports an arbitrary number of cert formats without creating the need for an additional record every time an application wants a different type of cert. > If the model is the only part validated is the public key in the > cert, that means that DNS resolver, DNS APIs, and authorities need > to be aware of the X.509 format. Why is that? Only the application needs to be aware of X.509 (or, in the case of OpenPGP via TLS, an OpenPGP key). Once it gets the key out , it hashes it and checks it against the DNS hierarchy. > But if the entire record is just validated as a single binary blob, > this means that different certificate formats could be used in the > future without needing to change anything other than the application > which is the final consumer of the new certificate type. You would be forcing one of two things, either: a. every application must be updated to use whatever cert standard you chose b. you must add duplicate entries for each public key for each new cert standard you chose Neither seems optimal. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9BF3A6817 for ; Mon, 23 Aug 2010 08:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.492 X-Spam-Level: X-Spam-Status: No, score=-1.492 tagged_above=-999 required=5 tests=[AWL=1.107, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KilfZW9qwSH5 for ; Mon, 23 Aug 2010 08:40:53 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 07B0D3A657C for ; Mon, 23 Aug 2010 08:40:52 -0700 (PDT) Received: by pvg7 with SMTP id 7so2700458pvg.31 for ; Mon, 23 Aug 2010 08:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DCjfrFk8HgOvSgq0atuhARwDk0jeVYObjR1Oph544/w=; b=i6vml8UHh2e0XQaPoBomCKZ9wpdyA1sQW0jLOm2zAmeOdXC0qygjMIhsLPFdSWZecd YaFql11e82a/vTu3D2W6/B3kfFX3kqvJ9zzfO12toAays7IruQwfYsi4zQZF/K1kq4M0 EirPjojG3utYOVRKqJCLleHu9++tWibfE/19c= 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:content-transfer-encoding; b=ds1Wvry4dqPUeaLbF4ibWrqvP9hSFgZ0QxPp4NmVvvL3w8CJw0395FloWlscOZdZA+ C08Z1TNOktKGrpcVNlZknDQWAAjPFiVeP7vwbtKoPmE/4KC1fYjt6AbI9Zu5IJK015a8 vQnqfQmzu475iv/x2SR3kK4bi2lJrde2ixQXw= MIME-Version: 1.0 Received: by 10.142.133.8 with SMTP id g8mr4219769wfd.96.1282578086420; Mon, 23 Aug 2010 08:41:26 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Mon, 23 Aug 2010 08:41:26 -0700 (PDT) In-Reply-To: References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> Date: Mon, 23 Aug 2010 11:41:26 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 15:40:54 -0000 I think the argument here is that making the hash cover only the key means that the DNS processing layer needs to be aware of much more of the internals of the cert format than he would like. I agree. Putting the authentication round the whole cert is much cleaner and means that there is a better layer separation. On Mon, Aug 23, 2010 at 11:36 AM, Paul Wouters wrote: > On Mon, 23 Aug 2010, Nicholas Weaver wrote: > >>> I can understand using the container X.509 format, but it should really >>> (IMHO) be limited to just the verification of the public key. >> >> Except that, IMO, there is a huge advantage to be had on simplicity of >> just verifying the ENTIRE certificate. =A0Who says CERT RR's need to be = just >> X.509 format? > > So what is wrong with RFC 4398? You already have that. Your app grabs > the CERT via CERT RR and then your application can do all its Cert/CA > based validation it wants to. I am not saying that is wrong - I just > don't understand why you need another RFC for that. > > I think there is a strong desire to have the option of not using X.509 > or PKIX at all, and base validation and verification purely on DNSSEC > as a trust model. > > I thought this group was to work on a good standard for those > applications, and that those who want to use certs, can stick with using > RFC 4398 (or non-DNS based validation, eg EVR) > > Paul > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB60B3A6817 for ; Mon, 23 Aug 2010 08:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.734, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Dit9QtTCsGi for ; Mon, 23 Aug 2010 08:39:14 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id C48303A657C for ; Mon, 23 Aug 2010 08:39:14 -0700 (PDT) Received: by pvg7 with SMTP id 7so2699488pvg.31 for ; Mon, 23 Aug 2010 08:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=g5k9pLYZ5S81Ux6pCfmYpu/TMhsYcnz3orF2e10rYlQ=; b=K5Sa/Z4iKX9CY3+l5N+NRIpLGoMV7+R41c4JboULNy4JBkz90ajglcozUPmr1Ufszu 53TGRPIbzEjW6V27eaj1k5N1U8IccjBUOsElSTTA8Ws6Erd9S0m1AZ7eZ/lC5aYEJ0mt /c0Ey6kTIjtqtGXraTC4Om/F1XtSnksdZpn6A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=o3Q297O2+w56/mfpznQ/Z/h9lKqjydBaUroElIRyc8IRsIwOgk9vxpN/ISItDbsCoq 3bjKdYkO3g8R0EPGThEWZvH8uuMrUcBheOk2r2mEGdzq59i/VtfRy4zp5nXFcXfGFys4 DYmxzyIdQ/4NI7Y53AaaPmIo7kFBvgwxBg9HA= Received: by 10.142.226.18 with SMTP id y18mr4497071wfg.239.1282577988405; Mon, 23 Aug 2010 08:39:48 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id n2sm8658332wfl.13.2010.08.23.08.39.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Aug 2010 08:39:47 -0700 (PDT) Sender: Nicholas Weaver References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <1C4ED82F-D56D-4362-914F-C41A44327901@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Mon, 23 Aug 2010 08:39:45 -0700 To: Paul Wouters X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, Nicholas Weaver Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 15:39:16 -0000 On Aug 23, 2010, at 8:36 AM, Paul Wouters wrote: > On Mon, 23 Aug 2010, Nicholas Weaver wrote: >=20 >>> I can understand using the container X.509 format, but it should = really >>> (IMHO) be limited to just the verification of the public key. >>=20 >> Except that, IMO, there is a huge advantage to be had on simplicity = of just verifying the ENTIRE certificate. Who says CERT RR's need to be = just X.509 format? >=20 > So what is wrong with RFC 4398? You already have that. Your app grabs > the CERT via CERT RR and then your application can do all its Cert/CA > based validation it wants to. I am not saying that is wrong - I just > don't understand why you need another RFC for that. Except you still need an API to understand the DNSSEC chain involved in = validating that CERT binary blob and to handle failures in a reasonable = manner... > I think there is a strong desire to have the option of not using X.509 > or PKIX at all, and base validation and verification purely on DNSSEC > as a trust model. I think of CERTs as not really requiring PKIX, eg, self-signed certs = become much more useful if they are validated through DNSSEC. > I thought this group was to work on a good standard for those > applications, and that those who want to use certs, can stick with = using > RFC 4398 (or non-DNS based validation, eg EVR) In many ways, I somewhat agree, but for a different reason: CERT RRs = are just a perfectly fine container class. We probably don't need new = RR types. What we need is ways of using such container classes with DNSSEC: this = doesn't add any new to-the-wire representatiton, but does require new = ways (APIs, naming conventions) of using the DNSSEC data, both at a low = level (APIs) and high level ("cookbook recipies"). Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C85BE3A68AF for ; Mon, 23 Aug 2010 08:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpgvpIEztu97 for ; Mon, 23 Aug 2010 08:35:38 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 54CC43A657C for ; Mon, 23 Aug 2010 08:35: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 7F873BC07; Mon, 23 Aug 2010 11:36:02 -0400 (EDT) Date: Mon, 23 Aug 2010 11:36:02 -0400 (EDT) From: Paul Wouters To: Nicholas Weaver In-Reply-To: <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> Message-ID: References: <871v9pu5ba.fsf@mocca.josefsson.org> <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 15:35:43 -0000 On Mon, 23 Aug 2010, Nicholas Weaver wrote: >> I can understand using the container X.509 format, but it should really >> (IMHO) be limited to just the verification of the public key. > > Except that, IMO, there is a huge advantage to be had on simplicity of just verifying the ENTIRE certificate. Who says CERT RR's need to be just X.509 format? So what is wrong with RFC 4398? You already have that. Your app grabs the CERT via CERT RR and then your application can do all its Cert/CA based validation it wants to. I am not saying that is wrong - I just don't understand why you need another RFC for that. I think there is a strong desire to have the option of not using X.509 or PKIX at all, and base validation and verification purely on DNSSEC as a trust model. I thought this group was to work on a good standard for those applications, and that those who want to use certs, can stick with using RFC 4398 (or non-DNS based validation, eg EVR) Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6E23A6816 for ; Mon, 23 Aug 2010 08:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfH8A87upvoO for ; Mon, 23 Aug 2010 08:19:28 -0700 (PDT) Received: from ppa02.Princeton.EDU (ppa02.Princeton.EDU [128.112.128.216]) by core3.amsl.com (Postfix) with ESMTP id 436B13A6803 for ; Mon, 23 Aug 2010 08:19:28 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa02.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7NFK1wq023959 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Aug 2010 11:20:01 -0400 Received: from [192.168.1.2] (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7NFK0SQ008726 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 11:20:01 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Schultze In-Reply-To: Date: Mon, 23 Aug 2010 11:20:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7C571132-83C8-4488-9256-694B2F7BC15A@Princeton.EDU> References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1077) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6082 signatures=637989 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008230099 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 15:19:29 -0000 On Aug 23, 2010, at 11:01 AM, Phillip Hallam-Baker wrote: > Given the choice between giving people with brains the information > they need to do the job right and not giving the information in case > it is misused by cretins, I suggest taking the first approach. I'm having trouble figuring out who the cretins vs the people with = brains are in your scenario, but fortunately it doesn't matter if we = design a system in which people can assert only what they are trusted to = assert. If your concern is... > SSL use can be controlled by key use bits and extensions in the cert. Then the answer is twofold: 1. these bits can continue to be used, and will be trusted if the CA is = trusted 2. if you wish to enforce this in the absence of a CA-trusted cert, we = can include an option in the RR standard for requiring SSL (which is an = assertion that the zone controller can be trusted to make) Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E65A3A68AE for ; Mon, 23 Aug 2010 08:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuPv6PVlX6za for ; Mon, 23 Aug 2010 08:19:08 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 6E3C33A6803 for ; Mon, 23 Aug 2010 08:19:08 -0700 (PDT) Received: by yxk8 with SMTP id 8so2517924yxk.31 for ; Mon, 23 Aug 2010 08:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=PJmXJA+gQuQRsHlTSFflDGIqRjhwk9GrSBHTtqy8rQU=; b=Km9zZei/Arn982i5Cv0n6ccZJGMA+M1zdLtpGkyF1UMDfTeGJ70n1RTsfwjpx6OWlJ tSUpQqgCLrdNKrTaqo+HEfUsgm1ZyIN2v0Q3YM/lKk+W9moSXfAngZz/JAR5wwjjuhV6 1dRpvMovoNfhxe3MrxrfVu10ss1F4QVISDsiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=C133VJGugKeRjpLMjnu26vvt+3+HmfUcyjE5zJWdHH+ns7LOnE4CrXc73VqDQI42+X d/0yDfWqbBxBAoaYBzNwZ0rIkbYGSDCVWNUWxlVYcFOGNFFvVjJDeCLkkHFLg5ic87fE 7K5rPXw51T9NZvfz/4yY4wS1JN0Dbi5BrvRhs= Received: by 10.150.2.11 with SMTP id 11mr5307764ybb.257.1282576781708; Mon, 23 Aug 2010 08:19:41 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id h8sm6286337ibk.21.2010.08.23.08.19.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Aug 2010 08:19:39 -0700 (PDT) Sender: Nicholas Weaver References: <871v9pu5ba.fsf@mocca.josefsson.org> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <8F386655-ECEE-4373-8150-4090B2B83F14@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Mon, 23 Aug 2010 08:19:35 -0700 To: Paul Wouters X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 15:19:09 -0000 On Aug 23, 2010, at 8:08 AM, Paul Wouters wrote: > On Mon, 23 Aug 2010, Simon Josefsson wrote: >=20 >> 2) The entire certificate, and even its chain, is confirmed by = Secure >> DNS. This allows the client to store the certificate locally and >> mark it as verified for a particular domain. Further, some >> applications is relying on the content of certificates (think >> X.509 extensions). With this proposal, the entire certificate is >> confirmed by DNSSEC, but with >> draft-hoffman-keys-linkage-from-dns-00 only the public key is >> directly confirmed. >=20 > This seems wrong to me. This is now mixing two authority sources, = DNSSEC > and the CA. And it introduced the possibility of conflicting = authoritve > sources. Other problems that come to mind are subjectAltnames that are > in the wrong spot in the DNS hierarchy. >=20 > I can understand using the container X.509 format, but it should = really > (IMHO) be limited to just the verification of the public key. Except that, IMO, there is a huge advantage to be had on simplicity of = just verifying the ENTIRE certificate. Who says CERT RR's need to be = just X.509 format? =20 If the model is the only part validated is the public key in the cert, = that means that DNS resolver, DNS APIs, and authorities need to be aware = of the X.509 format. =20 But if the entire record is just validated as a single binary blob, this = means that different certificate formats could be used in the future = without needing to change anything other than the application which is = the final consumer of the new certificate type. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03DE73A69DD for ; Mon, 23 Aug 2010 08:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoPwiWdrcgYx for ; Mon, 23 Aug 2010 08:14:51 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 7255F3A689F for ; Mon, 23 Aug 2010 08:14:51 -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 9FFF1C17D; Mon, 23 Aug 2010 11:15:24 -0400 (EDT) Date: Mon, 23 Aug 2010 11:15:24 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <871v9pu5ba.fsf@mocca.josefsson.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: "keyassure@ietf.org" Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 15:14:54 -0000 On Mon, 23 Aug 2010, Phillip Hallam-Baker wrote: > I have written code to parse asn.1 in JavaScript. It is really no biggie. A search for "ASN.1" at http://web.nvd.nist.gov/ gives me 13 hits. Openswan (the project I develop for) had to released two CVE's in 7 years. One of those was an ASN.1 bug. ASN.1 is not trivial, and it is really best avoided if possible. > * multiple has algorithms > * multiple certs per host for different protocols > * multiple certs per service for multiple hosts > * support dynamic port assignment > * nat friendly > * client side certs for machine to machine protocols > * validation of a cert that is in hand > * discovery of a cert bound to a service > > I can meet all of these with either the CERT record or a new RR But your list can also be changed s/cert/pubkey/g > I believe we still need a new RR for the purpose of telling clients what protocol enhancements to use when connecting to a service. For example, is tis on offer for imap. DNSSEC should allow me to answer that question with certainty. I do not want to overload CERT for that purpose. Yes, and ideally that new RR should come in as additional record when the query had some kind of EDNS option set. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274653A6A3F for ; Mon, 23 Aug 2010 08:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37ee+e4x+eFP for ; Mon, 23 Aug 2010 08:07:42 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 09FBC3A6A31 for ; Mon, 23 Aug 2010 08:07:42 -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 45581C17D; Mon, 23 Aug 2010 11:08:14 -0400 (EDT) Date: Mon, 23 Aug 2010 11:08:13 -0400 (EDT) From: Paul Wouters To: Simon Josefsson In-Reply-To: <871v9pu5ba.fsf@mocca.josefsson.org> Message-ID: References: <871v9pu5ba.fsf@mocca.josefsson.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: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 15:07:43 -0000 On Mon, 23 Aug 2010, Simon Josefsson wrote: > 2) The entire certificate, and even its chain, is confirmed by Secure > DNS. This allows the client to store the certificate locally and > mark it as verified for a particular domain. Further, some > applications is relying on the content of certificates (think > X.509 extensions). With this proposal, the entire certificate is > confirmed by DNSSEC, but with > draft-hoffman-keys-linkage-from-dns-00 only the public key is > directly confirmed. This seems wrong to me. This is now mixing two authority sources, DNSSEC and the CA. And it introduced the possibility of conflicting authoritve sources. Other problems that come to mind are subjectAltnames that are in the wrong spot in the DNS hierarchy. I can understand using the container X.509 format, but it should really (IMHO) be limited to just the verification of the public key. > D) It reduces DNS transfer sizes by splitting unrelated services into > separate domain names. Consider if EXAMPLE.COM has 100 different > services running all using TLS. With the CERT RR type in > draft-hoffman-keys-linkage-from-dns-00, a client querying for any > service will get the hash of the key used for all 100 services. This > causes an unnecessary high load on the DNS servers and increased > message sizes. This also seems to be able to conflict with valid key use as specified in the X.509 certificate extended properties. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609343A6817 for ; Mon, 23 Aug 2010 08:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcg9JlfAPc6u for ; Mon, 23 Aug 2010 08:00:55 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 370D93A657C for ; Mon, 23 Aug 2010 08:00:55 -0700 (PDT) Received: by pwi1 with SMTP id 1so2796982pwi.31 for ; Mon, 23 Aug 2010 08:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XjrBbZha4mNAV/PUl5p2Gz40NMPaB8vEyoxBm47SAoc=; b=eP/vOIAEskppewzRGghalPW2dNmdLsYSvnadC/fy8ylqsyGd0f6K7bhKqyWYHjzTgk ldOeQVrJMiFV30Hg2dQFVshgkGVWqyasreiAOFQ2NiQR3qQiAoxYQ8dtCm+0PwX0NVeA gv6PE+Jrxdn3EJpxPgZ1lbEKnQudyzz7fNyYQ= 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:content-transfer-encoding; b=BfcC5mlubtMrBOk7N4YsnFZlNNiBFIACLCh6Q4wPZrcRO+NNB6YZx9oK3ysO0MDRyp h6x4DM01rzFdawX9cpLmY/9HhbrIKqchRRr5BnIuV6U7+iii9a8vu9J+LJo/l6oOST/6 xxyKJvFLg3Kv672j4eCDtOhtIJY3YrSNpaoiQ= MIME-Version: 1.0 Received: by 10.114.134.9 with SMTP id h9mr6115598wad.5.1282575688509; Mon, 23 Aug 2010 08:01:28 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Mon, 23 Aug 2010 08:01:28 -0700 (PDT) In-Reply-To: <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> References: <871v9pu5ba.fsf@mocca.josefsson.org> <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> Date: Mon, 23 Aug 2010 11:01:28 -0400 Message-ID: From: Phillip Hallam-Baker To: Steve Schultze Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 15:00:56 -0000 SSL use can be controlled by key use bits and extensions in the cert. Given the choice between giving people with brains the information they need to do the job right and not giving the information in case it is misused by cretins, I suggest taking the first approach. Part of what I would like to see happen here is to focus attention on the difference between what is asserted in a cert and what is trustworthy. On Mon, Aug 23, 2010 at 10:47 AM, Steve Schultze wrote: > On Aug 23, 2010, at 9:45 AM, Phillip Hallam-Baker wrote: >> The hash has to go over the full cert data or else you are passing trust= ed attributes in an untrusted fashion. That would be utterly abominable sec= urity practice. > > How so? =A0The only way those attributes should be trusted is if a CA tha= t signed the cert is trusted, as I described. =A0If you trust the CA, then = the attributes are passed in a trusted fashion because the cert is signed. = =A0As such, it is irrelevant whether the hash presented by the zone control= ler covers those attributes. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF143A689C for ; Mon, 23 Aug 2010 07:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFPZBo2MbTyb for ; Mon, 23 Aug 2010 07:46:56 -0700 (PDT) Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id 261513A6A35 for ; Mon, 23 Aug 2010 07:46:56 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id o7NElJfQ018865 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Aug 2010 10:47:29 -0400 Received: from [192.168.1.2] (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7NElIh9026435 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 10:47:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Schultze In-Reply-To: Date: Mon, 23 Aug 2010 10:47:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <781622DC-8903-4A1F-AC6C-4CB3C1DD3185@Princeton.EDU> References: <871v9pu5ba.fsf@mocca.josefsson.org> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1077) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6082 signatures=637989 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008230092 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 14:46:57 -0000 On Aug 23, 2010, at 9:45 AM, Phillip Hallam-Baker wrote: > The hash has to go over the full cert data or else you are passing = trusted attributes in an untrusted fashion. That would be utterly = abominable security practice.=20 How so? The only way those attributes should be trusted is if a CA that = signed the cert is trusted, as I described. If you trust the CA, then = the attributes are passed in a trusted fashion because the cert is = signed. As such, it is irrelevant whether the hash presented by the = zone controller covers those attributes.= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E241F3A6A4C for ; Mon, 23 Aug 2010 06:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNY8WbCLWYMv for ; Mon, 23 Aug 2010 06:44:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 7989B3A6A3F for ; Mon, 23 Aug 2010 06:44:57 -0700 (PDT) Received: by ywi4 with SMTP id 4so2303714ywi.31 for ; Mon, 23 Aug 2010 06:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=v/bPavoBQJ568G//rm/yrjgvi7OWt7x4+DwxSgHe0gg=; b=ODshZyd8RmTqlcYY1BLiGEnkv53FV0nrr01oT/wv67+xbCCsftHfqtsQKR5hSIZSeR eTGkL26WZ9Jym4kaitwZL7ggjjW37RmZ2tLyyEbJSgayGqNBBalVjxqjgHsYZhDGcMQk rYUCFan5Y//1pBg3LXPkgS6yjtFd37k9J6pjw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=umwPFT6Fhn6HD1N8h+w3RpDvD1mueG6Fshbbxr19IKVjbxTP7z5JQUBJrg1R4gmsFR lVRmG6xaUVi1w92IMrCdqYjCtJQHsS0qRRDZrAfzcppXdOcv9BLhLtkGhcrTtLxosm8U CY4Nk+GOdmMXb2VBYaaTiFroivDqybnRP+GME= Received: by 10.100.244.1 with SMTP id r1mr5449326anh.96.1282571129933; Mon, 23 Aug 2010 06:45:29 -0700 (PDT) Received: from [10.0.0.166] ([64.241.37.140]) by mx.google.com with ESMTPS id e8sm6221267ibb.8.2010.08.23.06.45.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Aug 2010 06:45:28 -0700 (PDT) References: <871v9pu5ba.fsf@mocca.josefsson.org> Message-Id: From: Phillip Hallam-Baker To: Steve Schultze In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Mon, 23 Aug 2010 09:45:32 -0400 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:44:59 -0000 Reading asn.1 is really not difficult. Writing out DER encoding is = painful in the extreme because the designers made a major goof.=20 I have written code to parse asn.1 in JavaScript. It is really no = biggie. The hash has to go over the full cert data or else you are passing = trusted attributes in an untrusted fashion. That would be utterly = abominable security practice.=20 We could do with a set of design goals. I suggest as starters * multiple has algorithms * multiple certs per host for different protocols * multiple certs per service for multiple hosts * support dynamic port assignment=20 * nat friendly * client side certs for machine to machine protocols * validation of a cert that is in hand * discovery of a cert bound to a service I can meet all of these with either the CERT record or a new RR On the constraints side we have * must be wildcard safe=20 * ability to use wildcards to specify certs for wild carded services. I believe we still need a new RR for the purpose of telling clients what = protocol enhancements to use when connecting to a service. For example, = is tis on offer for imap. DNSSEC should allow me to answer that question = with certainty. I do not want to overload CERT for that purpose. Sent from my iPad On Aug 23, 2010, at 9:22 AM, Steve Schultze wrote: > Does this allow for wildcards in these CERT records? > What happens when there are multiple certs per service? How many = certs is too many? > Where in the record can you place options such as additional hash = algorithms, or do you expect this to remain static for all time? >=20 > On signing the entire cert (B.2.), I do not believe that the zone = operator is in the position to assert anything about the contents of the = cert other than the domain-to-key mapping. Any additional assertions = (such as company name) are validated by the CA that issued the cert, and = trusted because the CA is trusted. Even if bank-of-america.com signs a = cert saying that the domain owner is "Bank of America Corp.", there's no = reason for me to blindly trust that assertion simply because the zone = controller says it is so. The only reason to trust it is if a trusted = CA has signed the cert (in particular, the EV cert) and in that case = it's irrelevant whether the zone controller published the hash of the = entire cert or not. On the other hand, publishing a hash of only the = key means that client protocols that do not use X.509 certs can simply = do basic key exchange and check that against DNS. >=20 > On Aug 23, 2010, at 4:00 AM, Simon Josefsson wrote: >> Folks, >>=20 >> I have published the following document: >>=20 >> http://www.ietf.org/id/draft-josefsson-keyassure-tls-00.txt >>=20 >> It is similar to the draft-hoffman-keys-linkage-from-dns-00 document = and >> my inspiration for writing this came from that draft (thanks guys!). >> However, there are a number of essential differences: >>=20 >> A) It uses the CERT RR with no alternatives. I believe the CERT RR = is >> intended for this, or at least a very similar purpose, and it is >> exensible enough to support this approach. >>=20 >> B) It confirms the entire TLS Certificate structure rather than just = a >> X.509 public key. There are two important advantages with this: >>=20 >> 1) OpenPGP in TLS is supported directly, as is any other certificate >> based authentication scheme that is using the TLS Certificate >> structure. >>=20 >> 2) The entire certificate, and even its chain, is confirmed by = Secure >> DNS. This allows the client to store the certificate locally and >> mark it as verified for a particular domain. Further, some >> applications is relying on the content of certificates (think >> X.509 extensions). With this proposal, the entire certificate is >> confirmed by DNSSEC, but with >> draft-hoffman-keys-linkage-from-dns-00 only the public key is >> directly confirmed. >>=20 >> C) It makes it possible to have different services on the same port = but >> on different protocols (TCP vs UDP). In >> draft-hoffman-keys-linkage-from-dns-00 I do no see a way to run a >> DTLS service on UDP and a TLS service on TCP on the same port number >> and reliably learn the intended hash. >>=20 >> D) It reduces DNS transfer sizes by splitting unrelated services into >> separate domain names. Consider if EXAMPLE.COM has 100 different >> services running all using TLS. With the CERT RR type in >> draft-hoffman-keys-linkage-from-dns-00, a client querying for any >> service will get the hash of the key used for all 100 services. = This >> causes an unnecessary high load on the DNS servers and increased >> message sizes. >>=20 >> E) The RR data is only a hash value, and there are no binary integer >> encoding and variable length string issues. Administrators can add >> the hash value in DNS zone files by adding the record easily. >>=20 >> F) There is a one-to-one mapping between the RR in the zone file and = a >> particular TLS-enabled service. This means that it is possible to >> delegate authority for the RR to the person responsible for that >> TLS-enabled service. In draft-hoffman-keys-linkage-from-dns-00, if = a >> service on port 4711 changes RSA key, this leads to a CERT RR change >> even for the CERT RR used for port 443. In production environments, >> I would not want to touch the 443 CERT RR just because someone is >> adding an unrelated and potentially experimental service. >>=20 >> /Simon >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479573A6A5B for ; Mon, 23 Aug 2010 06:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWQ3ePEYSDIY for ; Mon, 23 Aug 2010 06:29:07 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 4C31D3A6A5A for ; Mon, 23 Aug 2010 06:29:07 -0700 (PDT) Received: by gwb20 with SMTP id 20so2453539gwb.31 for ; Mon, 23 Aug 2010 06:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=iQgi52Vy1G66TVXjw7i8M2nP5IBYExBk8Xjy3abFlTY=; b=RSBcYIIzX9IWmPxdgzi2J2mhsbEa4zF5iwutSdxlTTTdrGyOFHG4z3Q0gp8QA9xnwG DMu27/n002c2A7IH4nSLe9UP/iTwSnNrLXHYsXx25kxkngoKqAJ9sSdm9W9g+OVSYfvn ZzRT51Vot3iheZyvvXR8K1AAch4zSI+GOX8Io= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=P8x9GuyEJC0quNystoYhXxEXDeN1qPv5lYeFH19rlMBEJOQLAiMsHteNHLvMc6LKdD 0ke1goXnm2y4gv9tnOrZL6PSX7RCfUggr8sgdl9+4YqjPRKzvev/cXqkXRFOZCu1KFwq jdax8HC3WuJIOjyS9dOepkb2Oq+jJC4q0k4bc= Received: by 10.90.98.4 with SMTP id v4mr3497657agb.58.1282570180361; Mon, 23 Aug 2010 06:29:40 -0700 (PDT) Received: from [10.0.0.166] ([64.241.37.140]) by mx.google.com with ESMTPS id g31sm6210144ibh.16.2010.08.23.06.29.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Aug 2010 06:29:37 -0700 (PDT) References: <877hjkv20p.fsf@mocca.josefsson.org> Message-Id: From: Phillip Hallam-Baker To: Simon Josefsson In-Reply-To: <877hjkv20p.fsf@mocca.josefsson.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Mon, 23 Aug 2010 09:29:40 -0400 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] more early work X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:29:08 -0000 This works better than the original certain scheme. But I don't like the = binding to ports. It works for tls server security but not for ws-* = security and client side.=20 For example, how does this work for chat and voip protocols where the = port assignment is dynamic? I don't like binding to one hash algorithm either. If you want to avoid = having a dns hash field then we should use an asn1 oid in the hash = field. Cert handling code can already deal with those. One idea I had was to use the hash used in the cert signature to create = a prefix tag that goes in the dns. So to declare a binding for cert = fingerprint whdgchjwdgcjhdcwjhg at example.com there would be a record _whdgchjwdgcjhdcwjhg.example.com CERT 1 9 = http://repository.example.com/cert1 This approach works if you have the cert in hand when you validate. It = also means that we can use the CERT field for a URL link to the = repository where the cert can be pulled from. That helps when trying to use this scheme to support a key to be used = for key exchange with a dns resolver.=20 Then I got started thinking about what a wildcard record would do to = this.=20 There has to be authentication to the right of the RR type. I would like = authentication plus a URL to make the scheme fully general.=20 _whdgchjwdgcjhdcwjhg.example.com CERT 1 10 whdgchjwdgcjhdcwjhg _whdgchjwdgcjhdcwjhg.example.com CERT 1 8 http://example.com/cert1 Then in order to get binding to a specific service I would add in the = srv prefix. _whdgchjwdgcjhdcwjhg._http._tcp.example.com CERT .... Sorry about the presentation here. This is a real &)$)&$)$& to enter on = a touch screen without real copy and paste. Sent from my iPad On Aug 21, 2010, at 3:49 AM, Simon Josefsson = wrote: > Hi all. I wanted to point to two more earlier work in this area: >=20 > http://tools.ietf.org/html/draft-josefsson-siked-framework-00 > http://tools.ietf.org/html/draft-josefsson-pkix-dns-00 >=20 > The first one contains an overview of problems and solutions around = that > time and the goal was (IIRC) to do a BoF/WG at that time. I hope = things > go better this time! ;) >=20 > /Simon > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573CD3A6A35 for ; Mon, 23 Aug 2010 06:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPP6m6ymYheL for ; Mon, 23 Aug 2010 06:22:24 -0700 (PDT) Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id C59223A6A42 for ; Mon, 23 Aug 2010 06:22:24 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7NDMvLN026373 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 23 Aug 2010 09:22:57 -0400 Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7NDMuh9009398 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 09:22:57 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Schultze In-Reply-To: <871v9pu5ba.fsf@mocca.josefsson.org> Date: Mon, 23 Aug 2010 09:22:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <871v9pu5ba.fsf@mocca.josefsson.org> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1077) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6082 signatures=637989 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008230069 Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:22:26 -0000 Does this allow for wildcards in these CERT records? What happens when there are multiple certs per service? How many certs = is too many? Where in the record can you place options such as additional hash = algorithms, or do you expect this to remain static for all time? On signing the entire cert (B.2.), I do not believe that the zone = operator is in the position to assert anything about the contents of the = cert other than the domain-to-key mapping. Any additional assertions = (such as company name) are validated by the CA that issued the cert, and = trusted because the CA is trusted. Even if bank-of-america.com signs a = cert saying that the domain owner is "Bank of America Corp.", there's no = reason for me to blindly trust that assertion simply because the zone = controller says it is so. The only reason to trust it is if a trusted = CA has signed the cert (in particular, the EV cert) and in that case = it's irrelevant whether the zone controller published the hash of the = entire cert or not. On the other hand, publishing a hash of only the = key means that client protocols that do not use X.509 certs can simply = do basic key exchange and check that against DNS. On Aug 23, 2010, at 4:00 AM, Simon Josefsson wrote: > Folks, >=20 > I have published the following document: >=20 > http://www.ietf.org/id/draft-josefsson-keyassure-tls-00.txt >=20 > It is similar to the draft-hoffman-keys-linkage-from-dns-00 document = and > my inspiration for writing this came from that draft (thanks guys!). > However, there are a number of essential differences: >=20 > A) It uses the CERT RR with no alternatives. I believe the CERT RR is > intended for this, or at least a very similar purpose, and it is > exensible enough to support this approach. >=20 > B) It confirms the entire TLS Certificate structure rather than just a > X.509 public key. There are two important advantages with this: >=20 > 1) OpenPGP in TLS is supported directly, as is any other certificate > based authentication scheme that is using the TLS Certificate > structure. >=20 > 2) The entire certificate, and even its chain, is confirmed by = Secure > DNS. This allows the client to store the certificate locally and > mark it as verified for a particular domain. Further, some > applications is relying on the content of certificates (think > X.509 extensions). With this proposal, the entire certificate is > confirmed by DNSSEC, but with > draft-hoffman-keys-linkage-from-dns-00 only the public key is > directly confirmed. >=20 > C) It makes it possible to have different services on the same port = but > on different protocols (TCP vs UDP). In > draft-hoffman-keys-linkage-from-dns-00 I do no see a way to run a > DTLS service on UDP and a TLS service on TCP on the same port number > and reliably learn the intended hash. >=20 > D) It reduces DNS transfer sizes by splitting unrelated services into > separate domain names. Consider if EXAMPLE.COM has 100 different > services running all using TLS. With the CERT RR type in > draft-hoffman-keys-linkage-from-dns-00, a client querying for any > service will get the hash of the key used for all 100 services. = This > causes an unnecessary high load on the DNS servers and increased > message sizes. >=20 > E) The RR data is only a hash value, and there are no binary integer > encoding and variable length string issues. Administrators can add > the hash value in DNS zone files by adding the record easily. >=20 > F) There is a one-to-one mapping between the RR in the zone file and a > particular TLS-enabled service. This means that it is possible to > delegate authority for the RR to the person responsible for that > TLS-enabled service. In draft-hoffman-keys-linkage-from-dns-00, if = a > service on port 4711 changes RSA key, this leads to a CERT RR change > even for the CERT RR used for port 443. In production environments, > I would not want to touch the 443 CERT RR just because someone is > adding an unrelated and potentially experimental service. >=20 > /Simon > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC1AF3A6843 for ; Mon, 23 Aug 2010 06:05:17 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPn5jRYwrNEC for ; Mon, 23 Aug 2010 06:05:16 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 11DA93A6A38 for ; Mon, 23 Aug 2010 06:05:12 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7ND5fe3019369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Aug 2010 15:05:43 +0200 (CEST) Message-ID: <4C727225.8030600@mnt.se> Date: Mon, 23 Aug 2010 15:05:41 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre MIME-Version: 1.0 To: keyassure@ietf.org References: <6808CC4E-7D64-4092-AF20-A9B161BD2152@kirei.se> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Key linkage draft, -00 edition X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:05:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/22/2010 10:39 PM, Phillip Hallam-Baker wrote: > On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter wrote: >> On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote: >> >>> There are multiple design choices here: >>> >>> 1) Use TXT vs a new RR. >> >> The choices where actually CERT vs TXT vs new RR. > > CERT seems sub-optimal to me since in most connection oriented > protocols the cert is passed in band. That is the case for both SSL > and SSH and for WS-*. The only protocols I know of where the certs > need to be pulled out of band are email messaging and the world has > already rejected that approach for S/MIME. SAML and IMI (aka information card) uses quite a bit of XML-DSIG both in trust establishment and in the protocol flows (as I believe you know ;-)) and the world hasn't rejected those yet. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxyciUACgkQ8Jx8FtbMZnd62wCgpvYLJa5B3q8N1t402rypZ28y txAAn2nEY2wAZUfqw+tfOCwMal6b8LDQ =P7a0 -----END PGP SIGNATURE----- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68783A6A0C for ; Mon, 23 Aug 2010 05:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.695 X-Spam-Level: X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9IoIJonHtIg for ; Mon, 23 Aug 2010 05:13:38 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 2C4C83A69FE for ; Mon, 23 Aug 2010 05:13:37 -0700 (PDT) Received: from mocca (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7NCE5Qj026555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 14:14:07 +0200 From: Simon Josefsson To: keyassure@ietf.org References: <871v9pu5ba.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100823:keyassure@ietf.org::MmqdCdd0Mc/giHfi:Fn6A Date: Mon, 23 Aug 2010 14:14:03 +0200 In-Reply-To: <871v9pu5ba.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 23 Aug 2010 10:00:25 +0200") Message-ID: <87lj7xr0fo.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Subject: Re: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 12:13:42 -0000 Simon Josefsson writes: > However, there are a number of essential differences: I forgot this nice feature: G) The TLS library does not have to do ASN.1/DER decoding to find the public key to hash before comparing with the DNS data. A TLS library without ASN.1/DER but with X.509 certificate validation via CERT would be possible. Yay. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F2D13A67F8 for ; Mon, 23 Aug 2010 01:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.702 X-Spam-Level: X-Spam-Status: No, score=-102.702 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W473jAqZWzdw for ; Mon, 23 Aug 2010 01:00:11 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id A9D583A67CC for ; Mon, 23 Aug 2010 01:00:10 -0700 (PDT) Received: from mocca (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7N80Rdh011158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 23 Aug 2010 10:00:32 +0200 X-Hashcash: 1:22:100823:keyassure@ietf.org::kLAymJaTvW+26bDb:IeBF From: Simon Josefsson To: keyassure@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Mon, 23 Aug 2010 10:00:25 +0200 Message-ID: <871v9pu5ba.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Subject: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 08:00:12 -0000 Folks, I have published the following document: http://www.ietf.org/id/draft-josefsson-keyassure-tls-00.txt It is similar to the draft-hoffman-keys-linkage-from-dns-00 document and my inspiration for writing this came from that draft (thanks guys!). However, there are a number of essential differences: A) It uses the CERT RR with no alternatives. I believe the CERT RR is intended for this, or at least a very similar purpose, and it is exensible enough to support this approach. B) It confirms the entire TLS Certificate structure rather than just a X.509 public key. There are two important advantages with this: 1) OpenPGP in TLS is supported directly, as is any other certificate based authentication scheme that is using the TLS Certificate structure. 2) The entire certificate, and even its chain, is confirmed by Secure DNS. This allows the client to store the certificate locally and mark it as verified for a particular domain. Further, some applications is relying on the content of certificates (think X.509 extensions). With this proposal, the entire certificate is confirmed by DNSSEC, but with draft-hoffman-keys-linkage-from-dns-00 only the public key is directly confirmed. C) It makes it possible to have different services on the same port but on different protocols (TCP vs UDP). In draft-hoffman-keys-linkage-from-dns-00 I do no see a way to run a DTLS service on UDP and a TLS service on TCP on the same port number and reliably learn the intended hash. D) It reduces DNS transfer sizes by splitting unrelated services into separate domain names. Consider if EXAMPLE.COM has 100 different services running all using TLS. With the CERT RR type in draft-hoffman-keys-linkage-from-dns-00, a client querying for any service will get the hash of the key used for all 100 services. This causes an unnecessary high load on the DNS servers and increased message sizes. E) The RR data is only a hash value, and there are no binary integer encoding and variable length string issues. Administrators can add the hash value in DNS zone files by adding the record easily. F) There is a one-to-one mapping between the RR in the zone file and a particular TLS-enabled service. This means that it is possible to delegate authority for the RR to the person responsible for that TLS-enabled service. In draft-hoffman-keys-linkage-from-dns-00, if a service on port 4711 changes RSA key, this leads to a CERT RR change even for the CERT RR used for port 443. In production environments, I would not want to touch the 443 CERT RR just because someone is adding an unrelated and potentially experimental service. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37F13A681E for ; Sun, 22 Aug 2010 18:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.608 X-Spam-Level: X-Spam-Status: No, score=-5.608 tagged_above=-999 required=5 tests=[AWL=0.991, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLI7tsuFP0d5 for ; Sun, 22 Aug 2010 18:38:29 -0700 (PDT) Received: from relay002.lsu.edu (relay002.lsu.edu [130.39.6.157]) by core3.amsl.com (Postfix) with ESMTP id 2FB173A6978 for ; Sun, 22 Aug 2010 18:38:29 -0700 (PDT) Received: from lsu.edu (nir-stealth.lsu.edu [130.39.193.41]) (authenticated bits=0) by relay002.lsu.edu (8.13.8/8.13.8) with ESMTP id o7N1csAj022802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Aug 2010 20:38:58 -0500 Date: Sun, 22 Aug 2010 20:38:54 -0500 From: Anthony Iliopoulos To: Paul Hoffman Message-ID: <20100823013854.GA25451@lsu.edu> References: <6808CC4E-7D64-4092-AF20-A9B161BD2152@kirei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: clamav-milter 0.96.1 at relay002.lsu.edu X-Virus-Status: Clean Cc: Phillip Hallam-Baker , keyassure@ietf.org Subject: Re: [keyassure] Key linkage draft, -00 edition X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 01:38:32 -0000 On Sun, Aug 22, 2010 at 05:32:16PM -0700, Paul Hoffman wrote: > At 7:19 PM -0400 8/22/10, Phillip Hallam-Baker wrote: > >On Sun, Aug 22, 2010 at 5:08 PM, Warren Kumari wrote: > >> > >> On Aug 22, 2010, at 4:39 PM, Phillip Hallam-Baker wrote: > >> > >>> On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter wrote: > >>>> On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote: > >>>> > >>>>> There are multiple design choices here: > >>>>> > >>>>> 1) Use TXT vs a new RR. > >>>> > >>>> The choices where actually CERT vs TXT vs new RR. > >>> > >>> CERT seems sub-optimal to me since in most connection oriented > >>> protocols the cert is passed in band. That is the case for both SSL > >>> and SSH and for WS-*. The only protocols I know of where the certs > >>> need to be pulled out of band are email messaging and the world has > >>> already rejected that approach for S/MIME. > >>> > >>> Using CERT RRs means that the size of the messages will inevitably > >>> spill over the 512 byte DNS boundary and will be close to the 1500 > >>> byte Ethernet MTU. > >> > >> Which is why the discussion has been to publish the fingerprint / hash and not the key / cert itself... You get key and validate that FP matches... > > > >So in the context of TXT, CERT or new RR, you are agreed that this > >cannot be done with the CERT record? > > Not at all; see . I was actually about to respond that the CERT RR is extensible enough to accommodate the fingerprint easily; just allocate a new type value and the corresponding semantics, reserve one byte for the hash algorithm type and the rest of the cert section is the fingerprint, but apparently I had TLSFP in the back of my head. Reading through the draft again, I wonder what is the motivation behind including a TCP/UDP port number field. Although there is the provision for specifying that the FP is valid for all ports, what purpose is that field meant to serve ? It is introducing an additional authorization layer/dimension to the TLS process. What is the consumer of this restriction expected to be ? What if this needs to be more fine-grained e.g. allow only a specific transport, or a transport other than TCP/UDP ? Regards, Anthony Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF41C3A6978 for ; Sun, 22 Aug 2010 18:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPlGHRRa7a7m for ; Sun, 22 Aug 2010 18:35:15 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1F2C73A6832 for ; Sun, 22 Aug 2010 18:35:13 -0700 (PDT) Received: by iwn3 with SMTP id 3so5763469iwn.31 for ; Sun, 22 Aug 2010 18:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=dYjxgxermhU3Y5bdcky1c+X6rGFaERcyAZRhlNwwUVs=; b=a0XThBs9NAY+UdiV4X6PDzBqGDKoX96jfuMP/orBwAvdKlDEsVlFglOPg6Wt1SCvTM jgxM2Vcsc1hAj4WsA3wdqGpnp/XaDzaUypsDCdOLQ2zmiBpL2HNv0yh5PihewMpdI7bP Bzae5wBTq4DcE72gDSm9NWCtM/JLUWslVSn7M= 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=RRn8gcTmOXruIwqn7+GqQgEuV8OrsuYfH/d6bLfhxVSnHurygMzzFGVaEn+btJqYJr DYvJQia2VP9e9svwleth/6Mk5nxCInywm/U4g8rnA9IbqyxABSaTkJY8HrqrCsBAx9aj /AmmpLqF2j1TWA8l/WiHn1Q2h7Tws2SKLdZl4= MIME-Version: 1.0 Received: by 10.231.169.10 with SMTP id w10mr5795287iby.106.1282527347055; Sun, 22 Aug 2010 18:35:47 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Sun, 22 Aug 2010 18:35:46 -0700 (PDT) In-Reply-To: References: <6808CC4E-7D64-4092-AF20-A9B161BD2152@kirei.se> Date: Sun, 22 Aug 2010 21:35:46 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org Subject: Re: [keyassure] Key linkage draft, -00 edition X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 01:35:33 -0000 OK, I had forgotten that 4398 had introduced URL types for certs. So the principle that the cert record contain certs is already gone. Do existing servers support adding new CERT types any more easily than new RRs? How about storing a cert URL plus a hash? Two CERT records with the same tag or define a new subformat to contain both parts? As a practical matter we may have a bug in the standards process here since according to RFC 4398 creating new CERT types requires a standards action while assigning a new RR does not. Rereading 4398, it is really not apparent how a relying party gets from an SSL session initiation to a DNS cert record. It appears that the tag field was intended for this, but I don't see how it can work, the explanation is certainly rather vauge. I would suggest combining the CERT record with the protocol specific prefixing approach taken in DKIM. On Sun, Aug 22, 2010 at 8:32 PM, Paul Hoffman wrote: > At 7:19 PM -0400 8/22/10, Phillip Hallam-Baker wrote: >>On Sun, Aug 22, 2010 at 5:08 PM, Warren Kumari wrote: >>> >>> On Aug 22, 2010, at 4:39 PM, Phillip Hallam-Baker wrote: >>> >>>> On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter wrote: >>>>> On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote: >>>>> >>>>>> There are multiple design choices here: >>>>>> >>>>>> 1) Use TXT vs a new RR. >>>>> >>>>> The choices where actually CERT vs TXT vs new RR. >>>> >>>> CERT seems sub-optimal to me since in most connection oriented >>>> protocols the cert is passed in band. That is the case for both SSL >>>> and SSH and for WS-*. The only protocols I know of where the certs >>>> need to be pulled out of band are email messaging and the world has >>>> already rejected that approach for S/MIME. >>>> >>>> Using CERT RRs means that the size of the messages will inevitably >>>> spill over the 512 byte DNS boundary and will be close to the 1500 >>>> byte Ethernet MTU. >>> >>> Which is why the discussion has been to publish the fingerprint / hash and not the key / cert itself... You get key and validate that FP matches... >> >>So in the context of TXT, CERT or new RR, you are agreed that this >>cannot be done with the CERT record? > > Not at all; see . > > --Paul Hoffman, Director > --VPN Consortium > -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5113A67FA for ; Sun, 22 Aug 2010 17:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.059 X-Spam-Level: X-Spam-Status: No, score=-101.059 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEiaBBV5OM9s for ; Sun, 22 Aug 2010 17:31:50 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 94CB13A67FB for ; Sun, 22 Aug 2010 17:31:46 -0700 (PDT) Received: from [10.20.30.158] (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 o7N0WHw3017219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Aug 2010 17:32:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6808CC4E-7D64-4092-AF20-A9B161BD2152@kirei.se> Date: Sun, 22 Aug 2010 17:32:16 -0700 To: Phillip Hallam-Baker , Warren Kumari From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] Key linkage draft, -00 edition X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 00:31:53 -0000 At 7:19 PM -0400 8/22/10, Phillip Hallam-Baker wrote: >On Sun, Aug 22, 2010 at 5:08 PM, Warren Kumari wrote: >> >> On Aug 22, 2010, at 4:39 PM, Phillip Hallam-Baker wrote: >> >>> On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter wrote: >>>> On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote: >>>> >>>>> There are multiple design choices here: >>>>> >>>>> 1) Use TXT vs a new RR. >>>> >>>> The choices where actually CERT vs TXT vs new RR. >>> >>> CERT seems sub-optimal to me since in most connection oriented >>> protocols the cert is passed in band. That is the case for both SSL >>> and SSH and for WS-*. The only protocols I know of where the certs >>> need to be pulled out of band are email messaging and the world has >>> already rejected that approach for S/MIME. >>> >>> Using CERT RRs means that the size of the messages will inevitably >>> spill over the 512 byte DNS boundary and will be close to the 1500 >>> byte Ethernet MTU. >> >> Which is why the discussion has been to publish the fingerprint / hash and not the key / cert itself... You get key and validate that FP matches... > >So in the context of TXT, CERT or new RR, you are agreed that this >cannot be done with the CERT record? Not at all; see . --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94EC23A6881 for ; Sun, 22 Aug 2010 16:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCZ4gnBaPIJl for ; Sun, 22 Aug 2010 16:18:41 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 653BA3A686B for ; Sun, 22 Aug 2010 16:18:41 -0700 (PDT) Received: by iwn3 with SMTP id 3so5646730iwn.31 for ; Sun, 22 Aug 2010 16:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=09MioIZ1CC5rPJJ06oaWu2mPCCzBdX7hhkVAjbvd6nU=; b=YxmwDSbXCUTqISMTbGc7MQORFuzBRy+QBSAOUm+kLxLYNueKmWqf2C10AlE1ndTcrF 3VuTEE3eYIvo9RitT894Krp4DFd1+Db8XfEKMjLI7koFFEdGaF//XE2Xg7zK+Pg4lO0E KSyG0FgMs98t4933r8o/JVuYSNWK6j+I3Ho2E= 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=Qe7FvCDZFAXaOsx7jx5wMkYIvffOQIy48Gz+ZukKyzTpUJpGMGLZZSee2wz/aJYA19 8Jc/w4UmSar4rS+wh2645vba1BSwe/xEJhg0q8+ukoAr87pXdWkjWOoF1XpY2UorUwiU E7lrME/SVMRgXs4ot8QSW97mq3WDLw6bGWbU8= MIME-Version: 1.0 Received: by 10.231.182.201 with SMTP id cd9mr5605665ibb.21.1282519155021; Sun, 22 Aug 2010 16:19:15 -0700 (PDT) Received: by 10.231.34.137 with HTTP; Sun, 22 Aug 2010 16:19:14 -0700 (PDT) In-Reply-To: References: <6808CC4E-7D64-4092-AF20-A9B161BD2152@kirei.se> Date: Sun, 22 Aug 2010 19:19:14 -0400 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Key linkage draft, -00 edition X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 23:18:42 -0000 On Sun, Aug 22, 2010 at 5:08 PM, Warren Kumari wrote: > > On Aug 22, 2010, at 4:39 PM, Phillip Hallam-Baker wrote: > >> On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter wrote: >>> On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote: >>> >>>> There are multiple design choices here: >>>> >>>> 1) Use TXT vs a new RR. >>> >>> The choices where actually CERT vs TXT vs new RR. >> >> CERT seems sub-optimal to me since in most connection oriented >> protocols the cert is passed in band. That is the case for both SSL >> and SSH and for WS-*. The only protocols I know of where the certs >> need to be pulled out of band are email messaging and the world has >> already rejected that approach for S/MIME. >> >> Using CERT RRs means that the size of the messages will inevitably >> spill over the 512 byte DNS boundary and will be close to the 1500 >> byte Ethernet MTU. > > Which is why the discussion has been to publish the fingerprint / hash and not the key / cert itself... You get key and validate that FP matches... So in the context of TXT, CERT or new RR, you are agreed that this cannot be done with the CERT record? -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E9B3A6954 for ; Sun, 22 Aug 2010 14:08:08 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XVgsPmaxPxv for ; Sun, 22 Aug 2010 14:08:02 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 902A83A68D0 for ; Sun, 22 Aug 2010 14:08:02 -0700 (PDT) Received: from [192.168.0.221] (unknown [96.26.102.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id D440B2284819; Sun, 22 Aug 2010 17:07:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Sun, 22 Aug 2010 17:08:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6808CC4E-7D64-4092-AF20-A9B161BD2152@kirei.se> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1078) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Key linkage draft, -00 edition X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 21:08:09 -0000 On Aug 22, 2010, at 4:39 PM, Phillip Hallam-Baker wrote: > On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter = wrote: >> On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote: >>=20 >>> There are multiple design choices here: >>>=20 >>> 1) Use TXT vs a new RR. >>=20 >> The choices where actually CERT vs TXT vs new RR. >=20 > CERT seems sub-optimal to me since in most connection oriented > protocols the cert is passed in band. That is the case for both SSL > and SSH and for WS-*. The only protocols I know of where the certs > need to be pulled out of band are email messaging and the world has > already rejected that approach for S/MIME. >=20 > Using CERT RRs means that the size of the messages will inevitably > spill over the 512 byte DNS boundary and will be close to the 1500 > byte Ethernet MTU. Which is why the discussion has been to publish the fingerprint / hash = and not the key / cert itself... You get key and validate that FP = matches... W >=20 > Yes we can back off into TCP, but that does not work very well through > firewalls. I think we have a much cleaner approach using a new RR. >=20 >=20 >>> In this case the use of a new RR is relatively unproblematic since = we >>> are assuming or at least encouraging the use of DNSSEC to sign the >>> records and thus there is no need to support DNS servers that do not >>> support additional RRs. >>=20 >> There is more than serving unknown RRs - one should also consider the = provisioning side of things and the client API. >=20 > This was the deciding factor in DKIM. >=20 > While I think that there is a use for DNS key assurance without > DNSSEC, mine is a minority view and my support for unsigned key > assurance is strictly to try to hook them on using DNSSEC anyway. >=20 > If we are expecting DNSSEC, I think we can expect there to be an > assumption of some degree of flexibility for provisioning. And this > whole effort will require a new API set. Instead of gethostbyname, I > would see us using getserviceconnection call that takes the name and > protocol label as criteria and returns a trust path for evaluation. >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45EB3A67B2 for ; Sun, 22 Aug 2010 13:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KO5wG6qHtbX for ; Sun, 22 Aug 2010 13:38:45 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 41F7A3A6873 for ; Sun, 22 Aug 2010 13:38:45 -0700 (PDT) Received: by iwn3 with SMTP id 3so5525843iwn.31 for ; Sun, 22 Aug 2010 13:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=AqxtHgSl47uZIArKUDZ/U9v9na7nogt4qXpMJQTeRBk=; b=BLnqznkdVxfKWhomovmTg3+GU/D1JkY0SoXSZR7kj+dm59gZd5M2CneKJ6eD3V6YQi A6xtiWR/gC7kyAOfAD+Zvx8wrZ5uRVuc+LPfwsECiC3NHvOP9pNSNu+xjridBmErFNnj /pTXRKnZw6sDIG1TZ5+Toh3ukBZYY/GrOxvH0= 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=XGQXup9gf2wohTZMRZUNGZeBUi9e4wIGuPKkBqluSgCsfgSvejHhBL1gUNMq2WCZlO GEUlxqNNpsGixL+huCCXTpe+jNLPIoE4oiji7rfKkAUtW6LhHdKD3tWr7nkxakxTmqi9 dqByaGNO1Ni9wRoS+st5iQNoTzvaDIDlpgm4w= MIME-Version: 1.0 Received: by 10.231.34.70 with SMTP id k6mr5146231ibd.25.1282509558852; Sun, 22 Aug 2010 13:39:18 -0700 (PDT) Received: by 10.231.34.137 with HTTP; Sun, 22 Aug 2010 13:39:18 -0700 (PDT) In-Reply-To: <6808CC4E-7D64-4092-AF20-A9B161BD2152@kirei.se> References: <6808CC4E-7D64-4092-AF20-A9B161BD2152@kirei.se> Date: Sun, 22 Aug 2010 16:39:18 -0400 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Key linkage draft, -00 edition X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 20:38:46 -0000 On Sun, Aug 22, 2010 at 4:26 PM, Jakob Schlyter wrote: > On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote: > >> There are multiple design choices here: >> >> 1) Use TXT vs a new RR. > > The choices where actually CERT vs TXT vs new RR. CERT seems sub-optimal to me since in most connection oriented protocols the cert is passed in band. That is the case for both SSL and SSH and for WS-*. The only protocols I know of where the certs need to be pulled out of band are email messaging and the world has already rejected that approach for S/MIME. Using CERT RRs means that the size of the messages will inevitably spill over the 512 byte DNS boundary and will be close to the 1500 byte Ethernet MTU. Yes we can back off into TCP, but that does not work very well through firewalls. I think we have a much cleaner approach using a new RR. >> In this case the use of a new RR is relatively unproblematic since we >> are assuming or at least encouraging the use of DNSSEC to sign the >> records and thus there is no need to support DNS servers that do not >> support additional RRs. > > There is more than serving unknown RRs - one should also consider the provisioning side of things and the client API. This was the deciding factor in DKIM. While I think that there is a use for DNS key assurance without DNSSEC, mine is a minority view and my support for unsigned key assurance is strictly to try to hook them on using DNSSEC anyway. If we are expecting DNSSEC, I think we can expect there to be an assumption of some degree of flexibility for provisioning. And this whole effort will require a new API set. Instead of gethostbyname, I would see us using getserviceconnection call that takes the name and protocol label as criteria and returns a trust path for evaluation. -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927F13A686E for ; Sun, 22 Aug 2010 13:26:24 -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_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoC0Xcs27ZH5 for ; Sun, 22 Aug 2010 13:26:23 -0700 (PDT) Received: from mail.kirei.se (wagaya.kirei.se [91.206.174.10]) by core3.amsl.com (Postfix) with ESMTP id 34B513A6801 for ; Sun, 22 Aug 2010 13:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kirei.se; s=wagaya20060620; t=1282508813; bh=M5oOJ2rOfYvAJCzBbzo+yAuI+rfaWjevqlvy4Na7XFM=; h=Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tu6BqtssDfKkrl1yv+hcTWohoXTXVG2QSz2BXJRmGjVz+UwWz3O5CjFQDDkPi/Se0 g37zgJTVbqjRS0al5oL/IAqyaXJ24SeDkrPKdhe6qgVSdVQgMGFcvN8g1irmkKk+wx 2le8tQtZX2eeXdyq+Y2XmOK4cF9b95wCjF/pfnpg= Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Sun, 22 Aug 2010 22:26:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6808CC4E-7D64-4092-AF20-A9B161BD2152@kirei.se> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Key linkage draft, -00 edition X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 20:26:24 -0000 On 22 aug 2010, at 15.13, Phillip Hallam-Baker wrote: > There are multiple design choices here: >=20 > 1) Use TXT vs a new RR. The choices where actually CERT vs TXT vs new RR. > In this case the use of a new RR is relatively unproblematic since we > are assuming or at least encouraging the use of DNSSEC to sign the > records and thus there is no need to support DNS servers that do not > support additional RRs. There is more than serving unknown RRs - one should also consider the = provisioning side of things and the client API. jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1548B3A688F for ; Sun, 22 Aug 2010 06:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[AWL=1.669, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muN2XyyE0hVo for ; Sun, 22 Aug 2010 06:13:14 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id EE87E3A687C for ; Sun, 22 Aug 2010 06:13:13 -0700 (PDT) Received: by iwn3 with SMTP id 3so5217556iwn.31 for ; Sun, 22 Aug 2010 06:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lRnFr99ZEExK6t4qnKG8I/l5qanIysMTJ3QElBg1btc=; b=RuW9EiXmZzDydux6hVrJMVdLjpTeIrly8hXpANZyzDk2iJm7IfUdphVnxQUb02EnAG UpjDD0kRmDM/L8/DVT8hH+J3iupkAQzhwz57kh/a5hb5+p/wojqsWVaCRtVso1Mw36kI D/zJ8t/vXRo9iHXHak14bwPZc1gCikGsUfrFI= 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:content-transfer-encoding; b=r5nLAda0IhA+Lk+GMcNp/eAYdVGDNWEygbH1lJ3kTdWjOGCOWOIUNEUK42COamiFnt uaJh6fjeJDqrK60Hb1+1GY3wH/yQ0E2fqrAAQc56nyi84PnZiBfRAfdEoPw9pZMtidcQ wHMkhmqhULUL5RnME5c//EbAeBkaT9z4BrvDc= MIME-Version: 1.0 Received: by 10.231.153.5 with SMTP id i5mr4888352ibw.105.1282482823680; Sun, 22 Aug 2010 06:13:43 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Sun, 22 Aug 2010 06:13:43 -0700 (PDT) In-Reply-To: References: Date: Sun, 22 Aug 2010 09:13:43 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Key linkage draft, -00 edition X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 13:13:16 -0000 DKIM uses a TXT record because it was designed to work with existing DNS and inparticular with servers that do not support additional records. For example the Windows DNS server where Microsoft presented code from the server to dismiss claims to the effect that it could be used to publish additional records. There are multiple design choices here: 1) Use TXT vs a new RR. In this case the use of a new RR is relatively unproblematic since we are assuming or at least encouraging the use of DNSSEC to sign the records and thus there is no need to support DNS servers that do not support additional RRs. Conclusion: New RR 2) Use of an ASCII format field with internal syntax versus DNS binary fiel= d This is what I took Stephen to be suggesting. And I prefer this approach since it means that we adopt a tag-value structure and automatically gain the extensibility I believe is going to be necessary to make this protocol work. Those of us who have experience of DKIM know that this is going to prove rather more complex than the fixed binary draft on the table. I do not see a great value in trying to make the binary draft into an extensible scheme, the savings in bits are rather trivial, the complexity introduced into the code is considerable. In particular, I really don't want to go for a scheme that introduces yet another registry of code points to be registered for the tags in the tag value pairs. Different protocols are going to have different security requirements and some will require additional tags. In the world of Web Services, protocol designs are going to proliferate rapidly and creating choke points for code point assignment is going to discourage use of the scheme. Conclusion: Use ASCII 3) Use of existing DKIM tags versus new tags Reuse of the DKIM tags is a tricky question, it would be a good idea if we are going to use the same architecture and the tags can have the same semantics. Since we require different semantics I would prefer to use different tags since the same person is likely to be configuring both sets of tags and confusion is going to be rather likely. Here another design choice of DKIM may be significant, the choice of single letter tags in a UNIX style command line format. I dislike this approach as it means I have to always consult a manual to look at what the tags mean. Conclusion: Use different tags to those employed in DKIM 4) Use prefix records or per-protocol records. As we have seen, the fact that a key is acceptable for one protocol does not mean that it is acceptable for another. Consider a site that has a payment invoicing application and a Web site on the same domain name. We don't want to have the cross site scripting vulnerabilities in the Web site enabling an attacker to start authorizing invoices for payment (that would be bad). Here the question is whether we are only going to support a limited number of protocols or design something that can be used as generic infrastructure for Web Services. We already have several thousand Web Services in use. Protocols that involve humans tend to be rather limited in number. Anyone can write their own mail protocol, but people only want to use one mail application. So once SMTP appeared there was no room for new protocols. That constraint does not apply to Web services, payment gateways typically support a different protocol per payment processor (allegedly there is a standard - not). If we accept that there will be tens of thousands of Web Service protocols, burning a RR per protocol is clearly unacceptable. The objection made in the IAB options draft had to do with wildcards and prefixing TXT as a substitute for a new RR. These do not apply here since we are using a new RR and the wildcard issue is fixable if relevant. Conclusion: Use SRV style prefixes Putting these together, I see the following as the simplest example: _http._tcp.www.example.com OPTIONS "ssl=3Doffered certh=3Dsha256:0b92c7808b91f7dc1cadaf8f9afe4d9834372adcc3e18f1d 4df6704768eea870" If we have more than one cert: _smtp._tcp.example.com OPTIONS "ssl=3Doffered" cert1._smtp._tcp.example.com OPTIONS "certh=3D(3e8e64500a2ac1ea38203ef943c5e3188e1e537076b7846219996aa225e76c0e)= " cert2._smtp._tcp.example.com OPTIONS "certh=3D(a7fc2dcd765f94801bc06edd6420aad6cfe7fbfaa38113a5 e860a00607343b0d)" Where the certs have the corresponding labels cert1 and cert2 embedded as part of the issue process. On Thu, Aug 19, 2010 at 10:59 AM, Paul Hoffman wrot= e: >>Quick question: did you consider DKIM key records for this? >>(With a new "s=3D" value in the TXT RR.) >> >>If so, why don't they rate a mention? If not, maybe worth a >>look? > > First off, the idea of TXT RRs without _label prefixes has been mostly de= precated in the IETF. Second, the idea of saying "this isn't DKIM, it's thi= s new thing" by changing "s=3D" is begging for trouble. There are enough tr= icky semantics in the DKIM spec (not as many as in PKIX, but it sometimes f= eels that way) that reusing it would likely prevent us from having the free= dom we want. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E50183A68B1 for ; Sat, 21 Aug 2010 13:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.54 X-Spam-Level: X-Spam-Status: No, score=-1.54 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zDytHt9msvV for ; Sat, 21 Aug 2010 13:00:39 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 922B63A686E for ; Sat, 21 Aug 2010 13:00:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=STRISacHubqFeXrmBdfBAo0FMikLNfX+4F3267/OHyJaZPcgWdIJ5N+FkQl1SEoc; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.40] (helo=elwamui-milano.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OmuFd-0002BB-H3; Sat, 21 Aug 2010 16:01:13 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Sat, 21 Aug 2010 16:01:13 -0400 Message-ID: <5835419.1282420873513.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> Date: Sat, 21 Aug 2010 15:01:13 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: "keyassure@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688de869881c499ab6cacd5edf624d94366350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.40 Cc: william.barker@nist.gov Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 20:00:41 -0000 Phillip and all, Yes, and this tactic from David and Randy has been used many times before with unfortunately significant success. As such the Internet community has on occasion been damaged accordingly and to some degree suffers still as history has=20 clearly shown. -----Original Message----- >From: Phillip Hallam-Baker >Sent: Aug 20, 2010 5:08 PM >To: David Conrad >Cc: "keyassure@ietf.org" >Subject: Re: [keyassure] who to trust > >You know for people who say they want to focus on technology, you do >all keep digging. > >Damn right I consider forming PIR as a bidding consortium and >participating in a share of the profits on the award of the contract >to be a commercial relationship. > > >By the way, agenda denial is not a particularly effective tactic on >me. I keep attempting to engage on technical proposals, I note that >instead you and others prefer to focus on the assumptions on which my >proposals are based and make assertions that you then declare to be >off limits for discussion and then declare the conversation closed. > > >On Fri, Aug 20, 2010 at 5:25 PM, David Conrad wrote: >> Phillip, >> >> On Aug 20, 2010, at 1:09 PM, Phillip Hallam-Baker wrote: >>> Last I heard isoc has a financial interest in .org >> >> So, your logic is that because PIR has a contract with ICANN for the ope= ration of .ORG, ISOC receives money from PIR, and ISOC supports the IETF, t= hat this imputes a commercial relationship between IETF and ICANN? =C2=A0Re= ally? >> >>> Qualifying that with the weasel word direct and claiming it impacts my = credibility would seem to saymore about yours >> >> Riiight. =C2=A0As Randy Bush might say . >> >> Regards, >> -drc >> >> > > > >--=20 >Website: http://hallambaker.com/ >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, = strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liabilit= y depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.co= m Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9F6F3A6A56 for ; Sat, 21 Aug 2010 00:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.706 X-Spam-Level: X-Spam-Status: No, score=-102.706 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hluun3JNifNQ for ; Sat, 21 Aug 2010 00:49:03 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 679F33A6A51 for ; Sat, 21 Aug 2010 00:49:01 -0700 (PDT) Received: from mocca (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7L7nTP5015742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 21 Aug 2010 09:49:31 +0200 X-Hashcash: 1:22:100821:keyassure@ietf.org::3SdhDgLyegbDSEt/:LuZw From: Simon Josefsson To: keyassure@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Sat, 21 Aug 2010 09:49:26 +0200 Message-ID: <877hjkv20p.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Subject: [keyassure] more early work X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 07:49:06 -0000 Hi all. I wanted to point to two more earlier work in this area: http://tools.ietf.org/html/draft-josefsson-siked-framework-00 http://tools.ietf.org/html/draft-josefsson-pkix-dns-00 The first one contains an overview of problems and solutions around that time and the goal was (IIRC) to do a BoF/WG at that time. I hope things go better this time! ;) /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7049B3A699E for ; Fri, 20 Aug 2010 15:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7pQlbw0L9so for ; Fri, 20 Aug 2010 15:07:39 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 493053A6867 for ; Fri, 20 Aug 2010 15:07:39 -0700 (PDT) Received: by iwn3 with SMTP id 3so3724043iwn.31 for ; Fri, 20 Aug 2010 15:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=beeGMr+xk9vNNWwuQXEyvdf4OIPPVk68U3eq1ZlEes4=; b=SWKzq+vSAvI4mDMwwEaypIZpWDzbJFbqz1xNMKAlztDguiDRnuEOpElcH3kR5hour8 cm9NFf8Qkj9KXkDGQJNdkDO8oZ8zu7Usr9VsqIWD15ypQYovh4NLGM3WYiIdrAkyUNxe 5jcEX7eOmfwuAbj348HNHKV9bLCR18PIe5cFE= 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:content-transfer-encoding; b=iJaFUb+xcyarWbl8EStZaOdCQl7Ev3bVpKJjxwHcBZwuK2rbWG6WaKRfNRvZqVlM7c 97pSh0Ryn4E/kPv8g2q+4zcerSv8gYqhUmrGB5rmrxReI5/TbNlhNWLZjcY8PfHQvi2H qfVynqQdU5wM83DkVjdhUPhsUpGzET5LN/LSA= MIME-Version: 1.0 Received: by 10.231.147.131 with SMTP id l3mr2290231ibv.74.1282342093626; Fri, 20 Aug 2010 15:08:13 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Fri, 20 Aug 2010 15:08:13 -0700 (PDT) In-Reply-To: References: <4C6E5C4B.40904@Dartmouth.edu> <4C6E9978.2020500@nic.cz> <1C3E248A-339B-4DBC-AB9D-127F0F30BFEC@virtualized.org> Date: Fri, 20 Aug 2010 18:08:13 -0400 Message-ID: From: Phillip Hallam-Baker To: David Conrad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "keyassure@ietf.org" Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 22:07:40 -0000 You know for people who say they want to focus on technology, you do all keep digging. Damn right I consider forming PIR as a bidding consortium and participating in a share of the profits on the award of the contract to be a commercial relationship. By the way, agenda denial is not a particularly effective tactic on me. I keep attempting to engage on technical proposals, I note that instead you and others prefer to focus on the assumptions on which my proposals are based and make assertions that you then declare to be off limits for discussion and then declare the conversation closed. On Fri, Aug 20, 2010 at 5:25 PM, David Conrad wrote: > Phillip, > > On Aug 20, 2010, at 1:09 PM, Phillip Hallam-Baker wrote: >> Last I heard isoc has a financial interest in .org > > So, your logic is that because PIR has a contract with ICANN for the oper= ation of .ORG, ISOC receives money from PIR, and ISOC supports the IETF, th= at this imputes a commercial relationship between IETF and ICANN? =A0Really= ? > >> Qualifying that with the weasel word direct and claiming it impacts my c= redibility would seem to saymore about yours > > Riiight. =A0As Randy Bush might say . > > Regards, > -drc > > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC6F3A6955 for ; Fri, 20 Aug 2010 14:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=1.112, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pzMyp0WwrWR for ; Fri, 20 Aug 2010 14:43:57 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 0E1373A6A47 for ; Fri, 20 Aug 2010 14:43:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=A2gWodiUvZHfa7Cq6ZkQhZ07/H1/12TewWGu05zEWhqS54FYSYzFD7RwtVEUyNYp; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.50] (helo=mswamui-swiss.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OmZO0-0007S0-4Z; Fri, 20 Aug 2010 17:44:28 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 20 Aug 2010 17:44:27 -0400 Message-ID: <17928562.1282340668081.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> Date: Fri, 20 Aug 2010 16:44:28 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: David Conrad , Phillip Hallam-Baker Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688e75a06ef1334921e8862da9a8686b7cc350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.50 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 21:43:58 -0000 David and all, The financial relationship between PIR and the ISOC regarding .ORG one has to admit is symbiotic, but perhaps not a COI yet, But no one really knows that for sure do they? ICANN leadership has emphatically stated on more than one occasion that the IETF is ICANN's "Good right arm". So yes the arms length relationship between PIR/ICANN is two pronged at least. Still again this does not necessarly mean that there is 'problem' with such a relationship but the appearance of such gives some pause. There are also some strong potential positives in such relationships that can and do benifit everyone... -----Original Message----- >From: David Conrad >Sent: Aug 20, 2010 4:25 PM >To: Phillip Hallam-Baker >Cc: "keyassure@ietf.org" >Subject: Re: [keyassure] who to trust > >Phillip, > >On Aug 20, 2010, at 1:09 PM, Phillip Hallam-Baker wrote: >> Last I heard isoc has a financial interest in .org > >So, your logic is that because PIR has a contract with ICANN for the operation of .ORG, ISOC receives money from PIR, and ISOC supports the IETF, that this imputes a commercial relationship between IETF and ICANN? Really? > >> Qualifying that with the weasel word direct and claiming it impacts my credibility would seem to saymore about yours > >Riiight. As Randy Bush might say . > >Regards, >-drc > >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42B63A6A14 for ; Fri, 20 Aug 2010 14:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYsW8qPWgdbd for ; Fri, 20 Aug 2010 14:25:18 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id B6FF73A6A49 for ; Fri, 20 Aug 2010 14:25:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id DDDC0DCB0AB; Fri, 20 Aug 2010 14:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0gq9sp1NZD2; Fri, 20 Aug 2010 14:25:46 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id F206ADCB09A; Fri, 20 Aug 2010 14:25:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Fri, 20 Aug 2010 14:25:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C6E5C4B.40904@Dartmouth.edu> <4C6E9978.2020500@nic.cz> <1C3E248A-339B-4DBC-AB9D-127F0F30BFEC@virtualized.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: "keyassure@ietf.org" Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 21:25:28 -0000 Phillip, On Aug 20, 2010, at 1:09 PM, Phillip Hallam-Baker wrote: > Last I heard isoc has a financial interest in .org So, your logic is that because PIR has a contract with ICANN for the = operation of .ORG, ISOC receives money from PIR, and ISOC supports the = IETF, that this imputes a commercial relationship between IETF and = ICANN? Really? > Qualifying that with the weasel word direct and claiming it impacts my = credibility would seem to saymore about yours Riiight. As Randy Bush might say . Regards, -drc Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2753A69F7 for ; Fri, 20 Aug 2010 13:08: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELbzNlbLWHfg for ; Fri, 20 Aug 2010 13:08:40 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0907D3A6974 for ; Fri, 20 Aug 2010 13:08:39 -0700 (PDT) Received: by iwn3 with SMTP id 3so3612404iwn.31 for ; Fri, 20 Aug 2010 13:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=gqJF5Tq6H4NGy0dh25USlaN5BLCANwUOO0zVkUO/z44=; b=j41cIrG4qg1cK6TvMTCWrksFaj0mEzr1Zhwt+XKrqena/hTs8mTXDJULVq/m7kezOA 8j96RNkTwNRLoIZz5kER9pYA6Pz7Vyr44loR9x/xur5yTSVQNbfY2xdqQetF5oA92oJt xQaz2biihqcOPnEJTM2dSQ3TMaEfuHHsdl6zE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=tt8fStBFkUM1fitMJQSEk+mhVbPaW9yAquX/0b4ljW1hqB7GY4cuod+r2aYnafxBUS WsSGtEC+wb9jJjKeSpHmfNFubAf4L0VgUwvtItmJjPV9rYZmzk85O4LgosDKIZj31zax svVn339bVDDGvEbn7TRAmgOVOjA6usRFGaIMo= Received: by 10.231.157.135 with SMTP id b7mr1913523ibx.164.1282334954226; Fri, 20 Aug 2010 13:09:14 -0700 (PDT) Received: from [10.2.208.31] (mobile-166-137-138-028.mycingular.net [166.137.138.28]) by mx.google.com with ESMTPS id r3sm2884582ibk.19.2010.08.20.13.09.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Aug 2010 13:09:13 -0700 (PDT) References: <4C6E5C4B.40904@Dartmouth.edu> <4C6E9978.2020500@nic.cz> <1C3E248A-339B-4DBC-AB9D-127F0F30BFEC@virtualized.org> Message-Id: From: Phillip Hallam-Baker To: David Conrad In-Reply-To: <1C3E248A-339B-4DBC-AB9D-127F0F30BFEC@virtualized.org> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 20 Aug 2010 16:09:03 -0400 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 20:08:43 -0000 Last I heard isoc has a financial interest in .org Qualifying that with the weasel word direct and claiming it impacts my credibility would seem to saymore about yours Sent from my iPhone On 20 Aug 2010, at 14:08, David Conrad wrote: > On Aug 20, 2010, at 10:34 AM, Phillip Hallam-Baker wrote: >> Since DNSSEC is not deployed, it is clearly not fully understood. > > DNSSEC is deployed at the root, at a couple dozen TLDs, and about > 24,000 other zones (according to SecSpider). > >> I am not proposing a new trust scheme. I am proposing that we permit >> use of either the new trust scheme that you are proposing or the >> existing trust scheme that has a 15 year deployment history. > > I believe one of the reasons people are looking at DNSSEC as a way > to build a new PKI (to use a shorthand) is because the existing > trust schemes have significant flaws. I'm unclear as to why you'd > like to import those flaws into the efforts here, but Paul's > hypothesis would appear reasonable. > >> As for your imputation of a commercial motive here, I suggest that >> you >> consider whether you want to open up that topic of discussion. ICANN >> has a commercial relationship to IETF through ISOC. > > No it doesn't. This is no direct relationship, commercial or > otherwise, between ICANN and ISOC. I'm curious why you think there > would be. There is a relationship between ICANN and the IETF (IASA, > IAOC, whatever) in the form of performance SLAs for registry > modifications, but I have difficulty seeing this as commercial or in > any way related to keyassure. > > You really should stop making things up -- it damages your > credibility. > > Regards, > -drc > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605573A6844 for ; Fri, 20 Aug 2010 12:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=0.830, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_31=0.6, MANGLED_YOUR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XKZWcNlXzkP for ; Fri, 20 Aug 2010 12:04:56 -0700 (PDT) Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id 66F033A67B2 for ; Fri, 20 Aug 2010 12:04:56 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7KJ5UEr022903 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 20 Aug 2010 15:05:30 -0400 Received: from [192.168.2.100] (m3a2436d0.tmodns.net [208.54.36.58]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7KJ4aSQ011725 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Aug 2010 15:05:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Schultze In-Reply-To: Date: Fri, 20 Aug 2010 15:04:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E123C75-DBC7-4F1B-B146-9B02C2488010@princeton.edu> References: <4C6E5C4B.40904@Dartmouth.edu> <4C6E9978.2020500@nic.cz> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1077) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6080 signatures=637961 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008200117 Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 19:04:57 -0000 On Aug 20, 2010, at 1:34 PM, Phillip Hallam-Baker wrote: > Since my scheme is already deployed and should be well understood by > all participating in these discussions, I fail to see why there is a > need for a draft on my part. If you understand the browser trust root > model you will understand my proposal as being a logical refinement > thereof to introduce more accountability just as I did with my > proposal for EV certs. What is your proposed scheme? All I can find is: On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote: > The simple solution for this is to allow for certs in the dnssec trust = path to validate KSKs. This would supplement the TLD signature if = available. Assuming I understand you correctly, it's not clear to me why this is = any more secure than the current practice of CAs issuing certs for the = leaf node TLS keys themselves. Putting it in the DNSSEC trust path just = perhaps adds a dependency for the DNSSEC TA (I can't tell from your two = sentences if it's required to be signed and validated as such). If you = want (DNSSEC TA)+CA, zone controllers can just place the hash of each = leaf's CA-issued cert in DNS (which is compatible with the main thrust = of this group's proposed direction so far). If you'r proposing that = this is a mechanism for allowing third-party CAs to vouch for a KSK at = some higher level of the DNS hierarchy such that they create an = alternate trust hierarchy that subverts the exclusive domain-based = delegation of the TLDs (and further sub-domains), then there are a whole = host of questions which are most certainly outside the scope of what = most of us are trying to do here. As far as I can tell, none of this = would have any bearing on a proposed mechanism for placing DNSSEC-signed = leaf node key material in DNS (whether it chains to the ICANN root or = elsewhere, via locally specified TAs or your scheme). In any case, I don't intend this as an invitation to start a discussion = on the merits but rather as a demonstration of why an I-D and a separate = discussion seems appropriate to me as well.= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48BFF3A6B1E for ; Fri, 20 Aug 2010 11:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8STgbJI3ooq for ; Fri, 20 Aug 2010 11:08:30 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id D5CDB3A6AFC for ; Fri, 20 Aug 2010 11:08:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 13FD8DCA265; Fri, 20 Aug 2010 11:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EBjZbynwR+7; Fri, 20 Aug 2010 11:09:00 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 0F315DCA255; Fri, 20 Aug 2010 11:09:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Fri, 20 Aug 2010 11:08:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1C3E248A-339B-4DBC-AB9D-127F0F30BFEC@virtualized.org> References: <4C6E5C4B.40904@Dartmouth.edu> <4C6E9978.2020500@nic.cz> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 18:08:32 -0000 On Aug 20, 2010, at 10:34 AM, Phillip Hallam-Baker wrote: > Since DNSSEC is not deployed, it is clearly not fully understood. DNSSEC is deployed at the root, at a couple dozen TLDs, and about 24,000 = other zones (according to SecSpider). > I am not proposing a new trust scheme. I am proposing that we permit > use of either the new trust scheme that you are proposing or the > existing trust scheme that has a 15 year deployment history. I believe one of the reasons people are looking at DNSSEC as a way to = build a new PKI (to use a shorthand) is because the existing trust = schemes have significant flaws. I'm unclear as to why you'd like to = import those flaws into the efforts here, but Paul's hypothesis would = appear reasonable. =20 > As for your imputation of a commercial motive here, I suggest that you > consider whether you want to open up that topic of discussion. ICANN > has a commercial relationship to IETF through ISOC. No it doesn't. This is no direct relationship, commercial or otherwise, = between ICANN and ISOC. I'm curious why you think there would be. There = is a relationship between ICANN and the IETF (IASA, IAOC, whatever) in = the form of performance SLAs for registry modifications, but I have = difficulty seeing this as commercial or in any way related to keyassure. You really should stop making things up -- it damages your credibility. Regards, -drc Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C6A3A6AFC for ; Fri, 20 Aug 2010 10:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.424 X-Spam-Level: X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAAymQS+c7Nq for ; Fri, 20 Aug 2010 10:48:07 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id A38E53A6980 for ; Fri, 20 Aug 2010 10:48:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=s/5dXgEtIRR68XES8iosP8B5pyoCCDRiSA801chgszVunDUZBJxKx30CU0eNnb3U; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OmVho-00016L-Vj; Fri, 20 Aug 2010 13:48:40 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 20 Aug 2010 13:48:40 -0400 Message-ID: <29149168.1282326520964.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Fri, 20 Aug 2010 12:48:40 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: keyassure@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688328b3635d421051e2b73b92571bb256d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 Cc: william.barker@nist.gov Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 17:48:09 -0000 Paul and all, As you already know the 'Trust system' you refrence is not widely trusted. There inlies the crux of the problem and brings up multipul issues. I for one still contend that there never was, and still isn't a rough consensus in respect to the 'Trust system' to which your refrence in your remarks/statements below... That yet again re-stated and none the less, moving forward 'as is' is a compermise that we can supposedly attempt to move forward with in a constructive manner. -----Original Message----- >From: Paul Hoffman >Sent: Aug 20, 2010 12:11 PM >To: Phillip Hallam-Baker >Cc: keyassure@ietf.org >Subject: Re: [keyassure] who to trust > >I strongly support a charter that specifically ties the gaining of trust that a key/cert is associated with a domain name to the DNS itself, using the DNSSEC protocol as the cryptographic protection for the binding statements. Doing so uses a trust system that is well understood and a protocol that is well understood. > >It is fine to propose that a different trust system be used. In order to make that proposal understandable, you can write an Internet Draft that explains the trust system and compares it to the ones commonly in use today (PKIX certificates with CAs, OpenPGP certificates with web-of-trust, DNS responses signed with DNSSEC). > >It is fine to propose that DNS responses be used but to use a different cryptographic method for assuring the origin. In order to make that proposal understandable, you can write an Internet Draft that explains the new cryptographic binding, and compare it to DNSSEC. > >At 11:33 AM -0400 8/20/10, Phillip Hallam-Baker wrote: >>An IETF WG charter requires more than consensus amongst the proposers. >>There has to be an IETF consensus and the IESG has to concur and there >>has to be an AD willing to accept the WG. >> >>Making assertions and then ruling rebuttals as 'off topic' as you keep >>doing is not the way to get an IETF charter accepted. > >Yes, it is. > >Allowing one person to derail the charter discussion because he or his employer doesn't like where it is going is not considered a best practice in the IETF. Instead, if you think that you have a group of people that would support your view, start your own pre-BoF mailing list, show that you have an interested group, and bring that to the IESG. > >>If you want to persist in making a proposal which tries to enforce a >>certain trust model then it has to be in the security area. > >Your "has to be" and "must be" statements are not backed by any known precedent, are they? > >>I think >>you will find at least one of the security ADs rather skeptical of the >>viability of a single rooted model as even the US federal government >>could not come to agreement on that architecture. > >And, at that point, we can continue the discussion with them. So far, you are only speculating in a way that supports your (to this point) lone opinion. > >>Consensus does not mean that you get to choose a group of people who >>want to do it your way and then get a WG chartered to coronate that >>specific proposal. > >Nor does it mean listening to one person who repeats arguments over and over without gaining support from others in the discussion. Some of us prefer the former method to the one you are proposing. > >--Paul Hoffman, Director >--VPN Consortium >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1418A3A6B15 for ; Fri, 20 Aug 2010 10:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.7 X-Spam-Level: X-Spam-Status: No, score=-101.7 tagged_above=-999 required=5 tests=[AWL=0.899, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CR9+9IJ0ZZ6 for ; Fri, 20 Aug 2010 10:47:22 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 3D21D3A6980 for ; Fri, 20 Aug 2010 10:47:22 -0700 (PDT) Received: from crankycanuck.ca (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 8A0C41ECB408 for ; Fri, 20 Aug 2010 17:47:56 +0000 (UTC) Date: Fri, 20 Aug 2010 13:47:54 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20100820174754.GH96071@shinkuro.com> References: <4C6E5C4B.40904@Dartmouth.edu> <4C6E9978.2020500@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 17:47:23 -0000 On Fri, Aug 20, 2010 at 01:34:30PM -0400, Phillip Hallam-Baker wrote: > Since DNSSEC is not deployed, it is clearly not fully understood. What are you talking about? It is so deployed. I can validate answers from the root. I can validate isoc.org from the root on down. If what you are claiming instead is that DNSSEC is not fully deployed always and everywhere, I don't think that premise even slightly supports your other claim that DNSSEC is not fully understood. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3263A6B0B for ; Fri, 20 Aug 2010 10:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.995 X-Spam-Level: X-Spam-Status: No, score=-0.995 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kqma+bZEZjdg for ; Fri, 20 Aug 2010 10:33:56 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 00EF13A6AF5 for ; Fri, 20 Aug 2010 10:33:55 -0700 (PDT) Received: by iwn3 with SMTP id 3so3499739iwn.31 for ; Fri, 20 Aug 2010 10:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0+juyDPTbNEx2hxbIoxdK7++PBfbevwj+EEyHeA8+Zk=; b=iGopKXnHVA+GX8x0HZyiBI3cSQppwBuLTvb6gxpaZOvF+Btv/xLxh7FL75T2EfDR/K eQlrjPvs7vff+7QNeSbTgTzTBxOBbXNcrmF4vOW1OzJVLPsDyGa7bJj6bXhnBEJ+R33r VHCSxMzOBt67brXQqC7PrLNFZCqSE5WhzPIpg= 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:content-transfer-encoding; b=LbYfl3BfZx0atSh4c/y8cqMhvgTBJ0dCA3ZAWX0nZf6TJ8/Uj7tXjWnBnp9UgOG2lw UVbFjvqMH/P7FGgtd4LP2YV3GiOUzEeWvivDwuB0TMVzTzOyCzr8tAiThwvQb2XQYEjZ N1+3kCYZyfWnbdr2da/0ceWBQXipKvSY2hWGY= MIME-Version: 1.0 Received: by 10.231.182.196 with SMTP id cd4mr1776549ibb.191.1282325670372; Fri, 20 Aug 2010 10:34:30 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Fri, 20 Aug 2010 10:34:30 -0700 (PDT) In-Reply-To: References: <4C6E5C4B.40904@Dartmouth.edu> <4C6E9978.2020500@nic.cz> Date: Fri, 20 Aug 2010 13:34:30 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 17:33:58 -0000 Since DNSSEC is not deployed, it is clearly not fully understood. I am not proposing a new trust scheme. I am proposing that we permit use of either the new trust scheme that you are proposing or the existing trust scheme that has a 15 year deployment history. Since my scheme is already deployed and should be well understood by all participating in these discussions, I fail to see why there is a need for a draft on my part. If you understand the browser trust root model you will understand my proposal as being a logical refinement thereof to introduce more accountability just as I did with my proposal for EV certs. However, should you be insisting that the only way that we can approach this problem is to do it your way and that we cannot listen to any other, then I am going to keep asking questions that my experience makes me know to be relevant and which you are not able to answer. As for your imputation of a commercial motive here, I suggest that you consider whether you want to open up that topic of discussion. ICANN has a commercial relationship to IETF through ISOC. None of us are communists (well hardly any). For the record, I was retired from April 2009 and only began discussions with Comodo a few months back. I made similar observations in my talk at RSA2010 when I was fully retired. I have made similar statements in the same time period on the IETF and DNSEXT list. If you recall, I objected to the notion that there be a single root for the BGP Security solution. I believe that your assertions in this regard are unhelpful, unfair and should be withdrawn immediately. On Fri, Aug 20, 2010 at 1:11 PM, Paul Hoffman wrote= : > I strongly support a charter that specifically ties the gaining of trust = that a key/cert is associated with a domain name to the DNS itself, using t= he DNSSEC protocol as the cryptographic protection for the binding statemen= ts. Doing so uses a trust system that is well understood and a protocol tha= t is well understood. > > It is fine to propose that a different trust system be used. In order to = make that proposal understandable, you can write an Internet Draft that exp= lains the trust system and compares it to the ones commonly in use today (P= KIX certificates with CAs, OpenPGP certificates with web-of-trust, DNS resp= onses signed with DNSSEC). > > It is fine to propose that DNS responses be used but to use a different c= ryptographic method for assuring the origin. In order to make that proposal= understandable, you can write an Internet Draft that explains the new cryp= tographic binding, and compare it to DNSSEC. > > At 11:33 AM -0400 8/20/10, Phillip Hallam-Baker wrote: >>An IETF WG charter requires more than consensus amongst the proposers. >>There has to be an IETF consensus and the IESG has to concur and there >>has to be an AD willing to accept the WG. >> >>Making assertions and then ruling rebuttals as 'off topic' as you keep >>doing is not the way to get an IETF charter accepted. > > Yes, it is. > > Allowing one person to derail the charter discussion because he or his em= ployer doesn't like where it is going is not considered a best practice in = the IETF. Instead, if you think that you have a group of people that would = support your view, start your own pre-BoF mailing list, show that you have = an interested group, and bring that to the IESG. > >>If you want to persist in making a proposal which tries to enforce a >>certain trust model then it has to be in the security area. > > Your "has to be" and "must be" statements are not backed by any known pre= cedent, are they? > >>I think >>you will find at least one of the security ADs rather skeptical of the >>viability of a single rooted model as even the US federal government >>could not come to agreement on that architecture. > > And, at that point, we can continue the discussion with them. So far, you= are only speculating in a way that supports your (to this point) lone opin= ion. > >>Consensus does not mean that you get to choose a group of people who >>want to do it your way and then get a WG chartered to coronate that >>specific proposal. > > Nor does it mean listening to one person who repeats arguments over and o= ver without gaining support from others in the discussion. Some of us prefe= r the former method to the one you are proposing. > > --Paul Hoffman, Director > --VPN Consortium > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F713A6AF3 for ; Fri, 20 Aug 2010 10:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.768 X-Spam-Level: X-Spam-Status: No, score=-99.768 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiMDr7eqqdlp for ; Fri, 20 Aug 2010 10:13:46 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 210203A6B0B for ; Fri, 20 Aug 2010 10:11:47 -0700 (PDT) Received: from [10.20.30.158] (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 o7KHCBvt071865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Aug 2010 10:12:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4C6E5C4B.40904@Dartmouth.edu> <4C6E9978.2020500@nic.cz> Date: Fri, 20 Aug 2010 10:11:53 -0700 To: Phillip Hallam-Baker From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 17:13:54 -0000 I strongly support a charter that specifically ties the gaining of trust that a key/cert is associated with a domain name to the DNS itself, using the DNSSEC protocol as the cryptographic protection for the binding statements. Doing so uses a trust system that is well understood and a protocol that is well understood. It is fine to propose that a different trust system be used. In order to make that proposal understandable, you can write an Internet Draft that explains the trust system and compares it to the ones commonly in use today (PKIX certificates with CAs, OpenPGP certificates with web-of-trust, DNS responses signed with DNSSEC). It is fine to propose that DNS responses be used but to use a different cryptographic method for assuring the origin. In order to make that proposal understandable, you can write an Internet Draft that explains the new cryptographic binding, and compare it to DNSSEC. At 11:33 AM -0400 8/20/10, Phillip Hallam-Baker wrote: >An IETF WG charter requires more than consensus amongst the proposers. >There has to be an IETF consensus and the IESG has to concur and there >has to be an AD willing to accept the WG. > >Making assertions and then ruling rebuttals as 'off topic' as you keep >doing is not the way to get an IETF charter accepted. Yes, it is. Allowing one person to derail the charter discussion because he or his employer doesn't like where it is going is not considered a best practice in the IETF. Instead, if you think that you have a group of people that would support your view, start your own pre-BoF mailing list, show that you have an interested group, and bring that to the IESG. >If you want to persist in making a proposal which tries to enforce a >certain trust model then it has to be in the security area. Your "has to be" and "must be" statements are not backed by any known precedent, are they? >I think >you will find at least one of the security ADs rather skeptical of the >viability of a single rooted model as even the US federal government >could not come to agreement on that architecture. And, at that point, we can continue the discussion with them. So far, you are only speculating in a way that supports your (to this point) lone opinion. >Consensus does not mean that you get to choose a group of people who >want to do it your way and then get a WG chartered to coronate that >specific proposal. Nor does it mean listening to one person who repeats arguments over and over without gaining support from others in the discussion. Some of us prefer the former method to the one you are proposing. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53413A696E for ; Fri, 20 Aug 2010 09:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.472 X-Spam-Level: X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ad5lu9CnxoHU for ; Fri, 20 Aug 2010 09:51:31 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 5F00E3A695B for ; Fri, 20 Aug 2010 09:51:31 -0700 (PDT) Received: by yxk8 with SMTP id 8so1519197yxk.31 for ; Fri, 20 Aug 2010 09:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qbpOVlxB6MXsm9W3a6Qr1PV63ahDD+p20Y0PpQP4D9U=; b=TF4MIXFt28ltwS2E/JsH+kTLmD7sLpf9WPcl0yBCJXTY6G0S7ry7oQI4+CSwRItzMa bVJeNdniuyC+kGS8bbZLu+nSNxtvlvqEEd8ar38Y9xKILJn1n9TOtwT84AQUBiuAZCki GwzurRlWSKLtBnhd+OCzUrpBUHLz5gabkTEdg= 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:content-transfer-encoding; b=XeM1GWUnJla+w7FCbX9wk+4VYHAxv2R5j/aWZyxIf4tmp/9LI3hzM+EpFmwYs6UyOn xDyYX6D6SgggMpW2XtyZXrjyN4qyPBME0hreWzrhV7MeI0F7QwJroNl61r8pvtwc/Ga4 kWIEWnuMxculJ3LuEIeqG0s78Qh2gWXVxIGDA= MIME-Version: 1.0 Received: by 10.150.7.14 with SMTP id 14mr2362050ybg.215.1282323125586; Fri, 20 Aug 2010 09:52:05 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Fri, 20 Aug 2010 09:52:05 -0700 (PDT) In-Reply-To: <4C6E89EE.5010304@nic.cz> References: <329621.1282251520679.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> <4C6E3BB8.5090707@nic.cz> <4C6E89EE.5010304@nic.cz> Date: Fri, 20 Aug 2010 12:52:05 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 16:51:32 -0000 That was a private, offlist email that you have now chosen to share with the whole list. While I probably should have remembered to flag it as [offlist], it is generally proper to take care not to do this sort of thing. Again, if you propose a technical infrastructure that has a dependency on one particular party, then the behavior of that party becomes relevant in the technical discussion. If you wish to avoid that you must design an architecture that removes the dependency. from Phillip Hallam-Baker to Ond=F8ej Sur=FD date Fri, Aug 20, 2010 at 7:49 AM subject Re: [keyassure] Charter discussion - Use of DNSSEC in applications mailed-by gmail.com On Fri, Aug 20, 2010 at 9:58 AM, Ond=F8ej Sur=FD wrote= : > On 20.8.2010 13:49, Phillip Hallam-Baker wrote: >> >> Seems to me that you are making statements and then ruling objections >> to those statements as off topic. > > You are ripping my words out of the context. =A0I am saying that this is = no > place to discuss whether we trust "ICANN, Verisign or USG". =A0This group= has > the proposed charter based on fact that we are going to use DNS and DNSSE= C, > and we trust it. > > Again this should be a place where the work is done, and not a chitchat l= ist > for discussing whether US companies are good or not. =A0And I ask all > participants to respect that. > >> - Show quoted text - >> Exactly. =A0The change of the trust model will be always scary. =A0But i= t >> is important to realize that we don't change overall level of security >> (in fact, we are improving it), just the trust model. >> >> >> Ondrej >> >> On Fri, Aug 20, 2010 at 4:24 AM, Ond=F8ej Sur=FD =A0= wrote: >>> >>> [moderator hat on] >>> This is really off-topic. =A0Please cease a discussion on who to trust. >>> This >>> group is to get work done and not to discuss irrelevant topics like thi= s. >>> =A0Don't clutter the mailing list, thanks. >>> [/moderator hat off] > > > -- > =A0Ond=F8ej Sur=FD > =A0vedouc=ED v=FDzkumu/Head of R&D department > =A0------------------------------------------- > =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC > =A0Americka 23, 120 00 Praha 2, Czech Republic > =A0mailto:ondrej.sury@nic.cz =A0 =A0http://nic.cz/ > =A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112 > =A0------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453E53A6ACC for ; Fri, 20 Aug 2010 08:58:27 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MskbbEpIOFcs for ; Fri, 20 Aug 2010 08:58:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 5A0843A6ABE for ; Fri, 20 Aug 2010 08:58:26 -0700 (PDT) Received: from ros-dhcp192-1-51-64.bbn.com ([192.1.51.64]:53128) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmTzf-000JlF-K8; Fri, 20 Aug 2010 11:58:59 -0400 Message-Id: <2CEA7CA0-31AD-4922-877A-C3C487B8E13D@bbn.com> From: "Richard L. Barnes" To: "Jeffrey A. Williams" In-Reply-To: <5464824.1282318313060.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Aug 2010 11:58:58 -0400 References: <5464824.1282318313060.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> X-Mailer: Apple Mail (2.936) Cc: Tony Finch , keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 15:58:27 -0000 If the goal is an IETF working group, then the topic is protocol design. "Key assurance" is a really inaccurate name. If I were choosing, I would have used something like "Name Authentication with DNSSEC Assertions" (NADA!). --Richard On Aug 20, 2010, at 11:31 AM, Jeffrey A. Williams wrote: > +2 > > But arn't we really concerned here more about key > assurance and less about protocol design? > > > -----Original Message----- >> From: "Richard L. Barnes" >> Sent: Aug 19, 2010 10:27 PM >> To: Paul Hoffman >> Cc: Tony Finch , keyassure@ietf.org >> Subject: Re: [keyassure] who to trust >> >> +1 >> >> All this trust anchor discussion is really irrelevant to protocol >> design. We just make the chains, the relying parties choose what >> trust anchors to hang them from. >> >> --Richard >> >> >> On Aug 19, 2010, at 9:16 PM, Paul Hoffman wrote: >> >>> At 2:01 AM +0100 8/20/10, Tony Finch wrote: >>>> It seems to me from this week's discussion that (exaggerating >>>> slightly) no >>>> one wants to trust the x.509 certificate authorities and no one >>>> wants to >>>> trust ICANN's DNSSEC root anchor. >>> >>> Exaggerating wildly, I would say. Who other than Phill have said >>> they don't trust ICANN's DNSSEC root anchor? >>> >>> --Paul Hoffman, Director >>> --VPN Consortium >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >> >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > Regards, > > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and > growing, strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > > "Credit should go with the performance of duty and not with what is > very > often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; > liability > depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. > div. of > Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com > Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993823A6AB1 for ; Fri, 20 Aug 2010 08:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.039 X-Spam-Level: X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TxeYxrEXW34 for ; Fri, 20 Aug 2010 08:43:30 -0700 (PDT) Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id 34A293A67E6 for ; Fri, 20 Aug 2010 08:43:30 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7KFi4Eh027082 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 20 Aug 2010 11:44:04 -0400 Received: from [192.168.2.100] (m395a36d0.tmodns.net [208.54.90.57]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7KFi0SQ015715 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Aug 2010 11:44:02 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Schultze In-Reply-To: Date: Fri, 20 Aug 2010 11:43:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <52404F29-15B9-4E8B-968C-2B6747344CE7@princeton.edu> References: <4C6E5C4B.40904@Dartmouth.edu> <4C6E9978.2020500@nic.cz> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1077) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6079 signatures=637947 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008200089 Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 15:43:31 -0000 I like Richard's alternative charter proposal, which incorporates much = of what Phillip wrote. If it's easier to get consensus for it without = paragraphs 2 and 3, that's fine. I think it does a good job of laying = out the problem area and scope, which includes the idea that zone = controllers directly place key material in their zone. I think that = this functionality is in effect a new (or at least augmented) trust = model, but Phillip doesn't think so given that his draft also included = language to this effect and he thinks we can't be talking about trust = models. Frankly I don't care whether we call it a trust model or not as = long as we get some work done. In any case, the question of trust _anchor_ selection is out of scope = according to both Richard and Phillip's drafts, so let's stop talking = about it. On Aug 20, 2010, at 11:33 AM, Phillip Hallam-Baker wrote: > An IETF WG charter requires more than consensus amongst the proposers. > There has to be an IETF consensus and the IESG has to concur and there > has to be an AD willing to accept the WG. >=20 > Making assertions and then ruling rebuttals as 'off topic' as you keep > doing is not the way to get an IETF charter accepted. >=20 >=20 > If you want to persist in making a proposal which tries to enforce a > certain trust model then it has to be in the security area. I think > you will find at least one of the security ADs rather skeptical of the > viability of a single rooted model as even the US federal government > could not come to agreement on that architecture. >=20 > Consensus does not mean that you get to choose a group of people who > want to do it your way and then get a WG chartered to coronate that > specific proposal. >=20 >=20 >=20 > On Fri, Aug 20, 2010 at 11:04 AM, Ond=F8ej Sur=FD = wrote: >> On 20.8.2010 16:46, Phillip Hallam-Baker wrote: >>>=20 >>> Plenty of people have asserted that the objective is to do PKI for >>> 'free'. Others have expressed the opinion that certain services are >>> 'overpriced'. >>>=20 >>> Those are pricing discussions. >>>=20 >>>=20 >>> If you read the other charter proposals you will see that they both >>> contain statements to the effect that the advantage the group seeks = to >>> realize is to enforce use of a single root of trust. Those are the >>> parts I find unacceptable. >>=20 >> Just to repeat what Paul already said. You seem to be the only one = who >> complains. Or is there anybody else who has similar objections? If = you are >> out there, please speak up. >>=20 >> I would like to remind you that the IETF process works on rough = consensus. >> Right now my feeling is that you are standing alone with your = opinions on >> what is acceptable and what is not. And that's a hardly rough = consensus to >> change the charter. >>=20 >> I don't want to say that I (and other people) won't hear your = complaints and >> won't change the charter, but "plenty of people" (to cite you) is = much >> closer to rough consensus. I would be happier to find a total 100% >> consensus on our work, but if you barricade yourself in your position = that >> would be very very hard to achieve. >>=20 >> I was told that standard IETF process is a way how to have things not = done >> and that I am naive to push this through IETF, but I would like to = prove >> them wrong. >>=20 >> Ondrej >> -- >> Ond=F8ej Sur=FD >> vedouc=ED v=FDzkumu/Head of R&D department >> ------------------------------------------- >> CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC >> Americka 23, 120 00 Praha 2, Czech Republic >> mailto:ondrej.sury@nic.cz http://nic.cz/ >> tel:+420.222745110 fax:+420.222745112 >> ------------------------------------------- >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >>=20 >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EB43A67B5 for ; Fri, 20 Aug 2010 08:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QQf5LJxMp1k for ; Fri, 20 Aug 2010 08:33:14 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 247F13A67E6 for ; Fri, 20 Aug 2010 08:33:14 -0700 (PDT) Received: by iwn3 with SMTP id 3so3409825iwn.31 for ; Fri, 20 Aug 2010 08:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=O2ylBHXryOhcFB+G2Tq8WHMS9yDR4XzsPgc2GUT07OU=; b=DTjQK/KvunzQ0CdheuJ2Eremr2cSs07h5OlEVDd5yGN00EmjkWyh4GAaWpLJUwenX+ VP+yDtz4mAN9zzcwPbncRDmzRCWtz+VdfcaXKb9XFUKMiINI6PMtvklXZRtM4ajvSdVb t7whLYUWBqayxtdslUDZd3486ocPHDttTO+1g= 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:content-transfer-encoding; b=rqsu2WPyk55vuogUj8xVGZikL57dTe1MTa5+f/avV9qAvvs/+A1nZB1EKAJU5doqAb F3ar1QXctrzW9jiyC/ToPw1MV7WWD8xdQp38MS5F080t60+f0I1Qkzo+61Cq2TAUAXIJ 3LMw2KYxao2DtAbOWdZX+q9D2PsBGPo6KxshM= MIME-Version: 1.0 Received: by 10.231.17.1 with SMTP id q1mr1844593iba.17.1282318428531; Fri, 20 Aug 2010 08:33:48 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Fri, 20 Aug 2010 08:33:48 -0700 (PDT) In-Reply-To: <4C6E9978.2020500@nic.cz> References: <4C6E5C4B.40904@Dartmouth.edu> <4C6E9978.2020500@nic.cz> Date: Fri, 20 Aug 2010 11:33:48 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 15:33:15 -0000 An IETF WG charter requires more than consensus amongst the proposers. There has to be an IETF consensus and the IESG has to concur and there has to be an AD willing to accept the WG. Making assertions and then ruling rebuttals as 'off topic' as you keep doing is not the way to get an IETF charter accepted. If you want to persist in making a proposal which tries to enforce a certain trust model then it has to be in the security area. I think you will find at least one of the security ADs rather skeptical of the viability of a single rooted model as even the US federal government could not come to agreement on that architecture. Consensus does not mean that you get to choose a group of people who want to do it your way and then get a WG chartered to coronate that specific proposal. On Fri, Aug 20, 2010 at 11:04 AM, Ond=F8ej Sur=FD wrot= e: > On 20.8.2010 16:46, Phillip Hallam-Baker wrote: >> >> Plenty of people have asserted that the objective is to do PKI for >> 'free'. Others have expressed the opinion that certain services are >> 'overpriced'. >> >> Those are pricing discussions. >> >> >> If you read the other charter proposals you will see that they both >> contain statements to the effect that the advantage the group seeks to >> realize is to enforce use of a single root of trust. Those are the >> parts I find unacceptable. > > Just to repeat what Paul already said. =A0You seem to be the only one who > complains. =A0Or is there anybody else who has similar objections? =A0If = you are > out there, please speak up. > > I would like to remind you that the IETF process works on rough consensus= . > =A0Right now my feeling is that you are standing alone with your opinions= on > what is acceptable and what is not. =A0And that's a hardly rough consensu= s to > change the charter. > > I don't want to say that I (and other people) won't hear your complaints = and > won't change the charter, but "plenty of people" (to cite you) is much > closer to rough consensus. =A0I would be happier to find a total 100% > consensus on our work, but if you barricade yourself in your position tha= t > would be very very hard to achieve. > > I was told that standard IETF process is a way how to have things not don= e > and that I am naive to push this through IETF, but I would like to prove > them wrong. > > Ondrej > -- > =A0Ond=F8ej Sur=FD > =A0vedouc=ED v=FDzkumu/Head of R&D department > =A0------------------------------------------- > =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC > =A0Americka 23, 120 00 Praha 2, Czech Republic > =A0mailto:ondrej.sury@nic.cz =A0 =A0http://nic.cz/ > =A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112 > =A0------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB503A6AB4 for ; Fri, 20 Aug 2010 08:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=1.245, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s7OUdfLTQN0 for ; Fri, 20 Aug 2010 08:31:19 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id A8A423A67E6 for ; Fri, 20 Aug 2010 08:31:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=TKLx+PIczHZiuw8XR8TiDsmmkIsrCLsgqBsD7yR/TmPwMKOpHVatLzHAIFF8pjei; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OmTZR-00039a-2p; Fri, 20 Aug 2010 11:31:53 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 20 Aug 2010 11:31:52 -0400 Message-ID: <5464824.1282318313060.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Fri, 20 Aug 2010 10:31:52 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: "Richard L. Barnes" , Paul Hoffman Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068820ef3d22a85dc98d4b7dbb6c0c5ff7bf350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.33 Cc: Tony Finch , keyassure@ietf.org Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 15:31:22 -0000 +2 But arn't we really concerned here more about key assurance and less about protocol design? -----Original Message----- >From: "Richard L. Barnes" >Sent: Aug 19, 2010 10:27 PM >To: Paul Hoffman >Cc: Tony Finch , keyassure@ietf.org >Subject: Re: [keyassure] who to trust > >+1 > >All this trust anchor discussion is really irrelevant to protocol >design. We just make the chains, the relying parties choose what >trust anchors to hang them from. > >--Richard > > >On Aug 19, 2010, at 9:16 PM, Paul Hoffman wrote: > >> At 2:01 AM +0100 8/20/10, Tony Finch wrote: >>> It seems to me from this week's discussion that (exaggerating >>> slightly) no >>> one wants to trust the x.509 certificate authorities and no one >>> wants to >>> trust ICANN's DNSSEC root anchor. >> >> Exaggerating wildly, I would say. Who other than Phill have said >> they don't trust ICANN's DNSSEC root anchor? >> >> --Paul Hoffman, Director >> --VPN Consortium >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E471F3A6AB7 for ; Fri, 20 Aug 2010 08:23:44 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoV8cOikX7+d for ; Fri, 20 Aug 2010 08:23:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 446F93A6AB5 for ; Fri, 20 Aug 2010 08:23:43 -0700 (PDT) Received: from ros-dhcp192-1-51-64.bbn.com ([192.1.51.64]:52914) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmTS5-000J3H-LL; Fri, 20 Aug 2010 11:24:17 -0400 Message-Id: From: "Richard L. Barnes" To: "Jeffrey A. Williams" In-Reply-To: <24227249.1282316914019.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Aug 2010 11:24:16 -0400 References: <24227249.1282316914019.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org, Phillip Hallam-Baker , Scott Rea Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 15:23:45 -0000 Let's try this again: Selection of trust anchors is not a topic for this list. Not that it's not important; it's just irrelevant for protocol engineering. On Aug 20, 2010, at 11:08 AM, Jeffrey A. Williams wrote: > Phillip and all, > > From a personal prefrence point of view only, I would > much prefer a single root of trust. But the practical > and technical side of me keeps such notions in check as > such notions are not realistic. Same would be so for > free PKI. Free PKI is not realistic. Inexpensive PKI > is definately possible and done now. However business > entities see t eh potential huge quick profit potential > and will likely put upward pressure on PKI costs. > > Back the roots of trust and trust models and methods. > > What we seem to be gradually moving towards is multipul > trust roots with the seemingly growing desire to do so > via a inside DNS method, OR the use of trust anchors > for validation of certs but with a simpler yet robust > means of providing same. So two of my questions are > for now: > > 1.) How many trust anchors is sufficient and/or trustworthy > and how is the trustworthyness of same determined? > > 2.)Key strength of certs: is NIST's current standard sufficient? > My answer to this currently is NO. > > 3.) Is the current trust chain for trusted anchors sufficient, > secure, and also consistantly trustworthy? > > What we do know is that there at least 5m domains that > by any reasonably thinking person are not presently > trustworthy and need to either become so via some > means of method, or be dispensed with entirely. > See: > > http://news.slashdot.org/story/10/08/16/214228/5-Million-Domains-Serving-Malware-Via-Netwo%7C > > http://blog.armorize.com/2010/08/smci-widget-by-network-solutions-still.html > http://www.net-security.org/malware_news.php?id=1431 > http://blog.armorize.com/2010/08/more-than-500000-network-solutions.html > > > -----Original Message----- >> From: Phillip Hallam-Baker >> Sent: Aug 20, 2010 9:46 AM >> To: "Richard L. Barnes" >> Cc: keyassure@ietf.org, Scott Rea >> Subject: Re: [keyassure] who to trust >> >> Plenty of people have asserted that the objective is to do PKI for >> 'free'. Others have expressed the opinion that certain services are >> 'overpriced'. >> >> Those are pricing discussions. >> >> >> If you read the other charter proposals you will see that they both >> contain statements to the effect that the advantage the group seeks >> to >> realize is to enforce use of a single root of trust. Those are the >> parts I find unacceptable. >> >> >> On Fri, Aug 20, 2010 at 10:40 AM, Richard L. Barnes >> wrote: >>>> If people want to propose a system with a single point of failure >>>> then >>>> that point of failure has to be on the table for discussion. The >>>> only >>>> reason I brought ICANN up is that others insisted that we only >>>> design >>>> a system where the only choice is to trust the ICANN monopoly. >>> >>> [Citation needed] >>> >>> >>>> I do not think that we want two separate groups, one to do DNSSEC >>>> for >>>> applications using only the ICANN root and a separate group for >>>> applications using a choice of roots. And even if we wanted to, I >>>> doubt that a charter of that nature could be accepted by the IESG. >>> >>> Obviously we don't, because this whole discussion is completely >>> unrelated to >>> a choice of trust anchors. DNSSEC and other protocols we develop >>> in the >>> IETF do not require any relying party to use any given trust >>> anchor. If you >>> want a concrete example, just look at the DLV. >>> >>> >>>> One other charter point. We cannot have any discussion of pricing >>>> of >>>> products or services (including 'free'). IETF rules have been quite >>>> lax on this point to date. However we have to take care not to be >>>> the >>>> group that brings down the lawyers. >>> >>> That seems kind of obvious. Who has expressed a desire to discuss >>> pricing? >>> >>> --Richard >>> >>> >>> >>> >>>> >>>> >>>> On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea >>>> >>>> wrote: >>>>> >>>>> On 8/19/2010 9:16 PM, Paul Hoffman wrote: >>>>>> >>>>>> At 2:01 AM +0100 8/20/10, Tony Finch wrote: >>>>>>> >>>>>>> It seems to me from this week's discussion that (exaggerating >>>>>>> slightly) >>>>>>> no >>>>>>> one wants to trust the x.509 certificate authorities and no >>>>>>> one wants >>>>>>> to >>>>>>> trust ICANN's DNSSEC root anchor. >>>>>> >>>>>> Exaggerating wildly, I would say. Who other than Phill have >>>>>> said they >>>>>> don't trust ICANN's DNSSEC root anchor? >>>>>> >>>>>> --Paul Hoffman, Director >>>>>> --VPN Consortium >>>>>> _______________________________________________ >>>>>> keyassure mailing list >>>>>> keyassure@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/keyassure >>>>> >>>>> Hmmm... nothing against ICANN personally, but lots against a >>>>> single point >>>>> of >>>>> failure, I prefer to share that responsibility around >>>>> >>>>> -- >>>>> Scott Rea >>>>> Sr PKI Architect (Contractor) >>>>> Em: Scott.Rea@Dartmouth.edu >>>>> >>>>> >>>>> _______________________________________________ >>>>> keyassure mailing list >>>>> keyassure@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/keyassure >>>>> >>>> >>>> >>>> >>>> -- >>>> Website: http://hallambaker.com/ >>>> _______________________________________________ >>>> keyassure mailing list >>>> keyassure@ietf.org >>>> https://www.ietf.org/mailman/listinfo/keyassure >>> >>> >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > Regards, > > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and > growing, strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > > "Credit should go with the performance of duty and not with what is > very > often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; > liability > depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. > div. of > Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com > Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E923A6954 for ; Fri, 20 Aug 2010 08:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=1.322, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oil1lfRS+JLj for ; Fri, 20 Aug 2010 08:19:16 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 98EC13A67B5 for ; Fri, 20 Aug 2010 08:19:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=Y8no+bJPz4ME06S1I0Im74QAw/TWHVOw0rQum15TYvr3OLXI1pUCsZsDg7kQxf79; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OmTNm-0003El-J7; Fri, 20 Aug 2010 11:19:50 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 20 Aug 2010 11:19:49 -0400 Message-ID: <10195104.1282317590339.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Fri, 20 Aug 2010 10:19:50 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: "Richard L. Barnes" , Phillip Hallam-Baker Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606885c05b462750122d21007cc62659425a6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.33 Cc: keyassure@ietf.org, Scott Rea Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 15:19:18 -0000 Richard and all, Do I understand you right stating what you said below differently, that your less concerned regarding the end points than ensuring that the binded keys to any domain name overlaying DNS is valid and/or good? If I do understand you right, than I see your point. But shouldn't we have a better/stronger and known trusted starting point? Can the user even assume same necessarly? -----Original Message----- >From: "Richard L. Barnes" >Sent: Aug 20, 2010 9:55 AM >To: Phillip Hallam-Baker >Cc: keyassure@ietf.org, Scott Rea >Subject: Re: [keyassure] who to trust > >Ah, I have only just now read the initial charter proposal that Warren >sent out. I agree that that one is too root-centric. > >But clearly the problem can be phrased more in terms of application >needs (binding keys to domain names) and validation paths (overlaid on >DNS) instead of what TAs those paths end in. That's what I tried to >do in my earlier proposal. > > > > >On Aug 20, 2010, at 10:46 AM, Phillip Hallam-Baker wrote: > >> Plenty of people have asserted that the objective is to do PKI for >> 'free'. Others have expressed the opinion that certain services are >> 'overpriced'. >> >> Those are pricing discussions. >> >> >> If you read the other charter proposals you will see that they both >> contain statements to the effect that the advantage the group seeks to >> realize is to enforce use of a single root of trust. Those are the >> parts I find unacceptable. >> >> >> On Fri, Aug 20, 2010 at 10:40 AM, Richard L. Barnes >> wrote: >>>> If people want to propose a system with a single point of failure >>>> then >>>> that point of failure has to be on the table for discussion. The >>>> only >>>> reason I brought ICANN up is that others insisted that we only >>>> design >>>> a system where the only choice is to trust the ICANN monopoly. >>> >>> [Citation needed] >>> >>> >>>> I do not think that we want two separate groups, one to do DNSSEC >>>> for >>>> applications using only the ICANN root and a separate group for >>>> applications using a choice of roots. And even if we wanted to, I >>>> doubt that a charter of that nature could be accepted by the IESG. >>> >>> Obviously we don't, because this whole discussion is completely >>> unrelated to >>> a choice of trust anchors. DNSSEC and other protocols we develop >>> in the >>> IETF do not require any relying party to use any given trust >>> anchor. If you >>> want a concrete example, just look at the DLV. >>> >>> >>>> One other charter point. We cannot have any discussion of pricing of >>>> products or services (including 'free'). IETF rules have been quite >>>> lax on this point to date. However we have to take care not to be >>>> the >>>> group that brings down the lawyers. >>> >>> That seems kind of obvious. Who has expressed a desire to discuss >>> pricing? >>> >>> --Richard >>> >>> >>> >>> >>>> >>>> >>>> On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea >>>> wrote: >>>>> >>>>> On 8/19/2010 9:16 PM, Paul Hoffman wrote: >>>>>> >>>>>> At 2:01 AM +0100 8/20/10, Tony Finch wrote: >>>>>>> >>>>>>> It seems to me from this week's discussion that (exaggerating >>>>>>> slightly) >>>>>>> no >>>>>>> one wants to trust the x.509 certificate authorities and no one >>>>>>> wants >>>>>>> to >>>>>>> trust ICANN's DNSSEC root anchor. >>>>>> >>>>>> Exaggerating wildly, I would say. Who other than Phill have said >>>>>> they >>>>>> don't trust ICANN's DNSSEC root anchor? >>>>>> >>>>>> --Paul Hoffman, Director >>>>>> --VPN Consortium >>>>>> _______________________________________________ >>>>>> keyassure mailing list >>>>>> keyassure@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/keyassure >>>>> >>>>> Hmmm... nothing against ICANN personally, but lots against a >>>>> single point >>>>> of >>>>> failure, I prefer to share that responsibility around >>>>> >>>>> -- >>>>> Scott Rea >>>>> Sr PKI Architect (Contractor) >>>>> Em: Scott.Rea@Dartmouth.edu >>>>> >>>>> >>>>> _______________________________________________ >>>>> keyassure mailing list >>>>> keyassure@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/keyassure >>>>> >>>> >>>> >>>> >>>> -- >>>> Website: http://hallambaker.com/ >>>> _______________________________________________ >>>> keyassure mailing list >>>> keyassure@ietf.org >>>> https://www.ietf.org/mailman/listinfo/keyassure >>> >>> >> >> >> >> -- >> Website: http://hallambaker.com/ > >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD283A6AB9 for ; Fri, 20 Aug 2010 08:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[AWL=1.411, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDi3VOr5ciPT for ; Fri, 20 Aug 2010 08:08:00 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 07CE33A6AB5 for ; Fri, 20 Aug 2010 08:08:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=Uu9VoySGwft1XmuAQuf5yn+QoKMHyiNoXVdhgMxHkQOoJoAuWgyvBomyfZ1buNAW; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OmTCr-0007AD-Vr; Fri, 20 Aug 2010 11:08:33 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 20 Aug 2010 11:08:33 -0400 Message-ID: <24227249.1282316914019.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Fri, 20 Aug 2010 10:08:33 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Phillip Hallam-Baker , "Richard L. Barnes" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688f49d1bf658f9331c241b35ab8e9ca3db350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.33 Cc: keyassure@ietf.org, Scott Rea Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 15:08:03 -0000 Phillip and all, From a personal prefrence point of view only, I would much prefer a single root of trust. But the practical and technical side of me keeps such notions in check as such notions are not realistic. Same would be so for=20 free PKI. Free PKI is not realistic. Inexpensive PKI is definately possible and done now. However business entities see t eh potential huge quick profit potential and will likely put upward pressure on PKI costs. Back the roots of trust and trust models and methods. What we seem to be gradually moving towards is multipul trust roots with the seemingly growing desire to do so via a inside DNS method, OR the use of trust anchors for validation of certs but with a simpler yet robust means of providing same. So two of my questions are=20 for now: 1.) How many trust anchors is sufficient and/or trustworthy and how is the trustworthyness of same determined? 2.)Key strength of certs: is NIST's current standard sufficient? My answer to this currently is NO. 3.) Is the current trust chain for trusted anchors sufficient, secure, and also consistantly trustworthy? What we do know is that there at least 5m domains that by any reasonably thinking person are not presently trustworthy and need to either become so via some means of method, or be dispensed with entirely. See: http://news.slashdot.org/story/10/08/16/214228/5-Million-Domains-Serving-Ma= lware-Via-Netwo%7C http://blog.armorize.com/2010/08/smci-widget-by-network-solutions-still.htm= l http://www.net-security.org/malware_news.php?id=3D1431 http://blog.armorize.com/2010/08/more-than-500000-network-solutions.html -----Original Message----- >From: Phillip Hallam-Baker >Sent: Aug 20, 2010 9:46 AM >To: "Richard L. Barnes" >Cc: keyassure@ietf.org, Scott Rea >Subject: Re: [keyassure] who to trust > >Plenty of people have asserted that the objective is to do PKI for >'free'. Others have expressed the opinion that certain services are >'overpriced'. > >Those are pricing discussions. > > >If you read the other charter proposals you will see that they both >contain statements to the effect that the advantage the group seeks to >realize is to enforce use of a single root of trust. Those are the >parts I find unacceptable. > > >On Fri, Aug 20, 2010 at 10:40 AM, Richard L. Barnes wrot= e: >>> If people want to propose a system with a single point of failure then >>> that point of failure has to be on the table for discussion. The only >>> reason I brought ICANN up is that others insisted that we only design >>> a system where the only choice is to trust the ICANN monopoly. >> >> [Citation needed] >> >> >>> I do not think that we want two separate groups, one to do DNSSEC for >>> applications using only the ICANN root and a separate group for >>> applications using a choice of roots. And even if we wanted to, I >>> doubt that a charter of that nature could be accepted by the IESG. >> >> Obviously we don't, because this whole discussion is completely unrelate= d to >> a choice of trust anchors. =C2=A0DNSSEC and other protocols we develop i= n the >> IETF do not require any relying party to use any given trust anchor. =C2= =A0If you >> want a concrete example, just look at the DLV. >> >> >>> One other charter point. We cannot have any discussion of pricing of >>> products or services (including 'free'). IETF rules have been quite >>> lax on this point to date. However we have to take care not to be the >>> group that brings down the lawyers. >> >> That seems kind of obvious. =C2=A0Who has expressed a desire to discuss = pricing? >> >> --Richard >> >> >> >> >>> >>> >>> On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea >>> wrote: >>>> >>>> =C2=A0On 8/19/2010 9:16 PM, Paul Hoffman wrote: >>>>> >>>>> At 2:01 AM +0100 8/20/10, Tony Finch wrote: >>>>>> >>>>>> It seems to me from this week's discussion that (exaggerating slight= ly) >>>>>> no >>>>>> one wants to trust the x.509 certificate authorities and no one want= s >>>>>> to >>>>>> trust ICANN's DNSSEC root anchor. >>>>> >>>>> Exaggerating wildly, I would say. Who other than Phill have said they >>>>> don't trust ICANN's DNSSEC root anchor? >>>>> >>>>> --Paul Hoffman, Director >>>>> --VPN Consortium >>>>> _______________________________________________ >>>>> keyassure mailing list >>>>> keyassure@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/keyassure >>>> >>>> Hmmm... nothing against ICANN personally, but lots against a single po= int >>>> of >>>> failure, I prefer to share that responsibility around >>>> >>>> -- >>>> Scott Rea >>>> Sr PKI Architect (Contractor) >>>> Em: Scott.Rea@Dartmouth.edu >>>> >>>> >>>> _______________________________________________ >>>> keyassure mailing list >>>> keyassure@ietf.org >>>> https://www.ietf.org/mailman/listinfo/keyassure >>>> >>> >>> >>> >>> -- >>> Website: http://hallambaker.com/ >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >> >> > > > >--=20 >Website: http://hallambaker.com/ >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, = strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liabilit= y depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.co= m Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293373A6AA0 for ; Fri, 20 Aug 2010 08:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-4R5+XYl9Vw for ; Fri, 20 Aug 2010 08:03:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 5D8173A67F4 for ; Fri, 20 Aug 2010 08:03:51 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id E5B42734353 for ; Fri, 20 Aug 2010 17:04:24 +0200 (CEST) Message-ID: <4C6E9978.2020500@nic.cz> Date: Fri, 20 Aug 2010 17:04:24 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <4C6E5C4B.40904@Dartmouth.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 15:03:54 -0000 On 20.8.2010 16:46, Phillip Hallam-Baker wrote: > Plenty of people have asserted that the objective is to do PKI for > 'free'. Others have expressed the opinion that certain services are > 'overpriced'. > > Those are pricing discussions. > > > If you read the other charter proposals you will see that they both > contain statements to the effect that the advantage the group seeks to > realize is to enforce use of a single root of trust. Those are the > parts I find unacceptable. Just to repeat what Paul already said. You seem to be the only one who complains. Or is there anybody else who has similar objections? If you are out there, please speak up. I would like to remind you that the IETF process works on rough consensus. Right now my feeling is that you are standing alone with your opinions on what is acceptable and what is not. And that's a hardly rough consensus to change the charter. I don't want to say that I (and other people) won't hear your complaints and won't change the charter, but "plenty of people" (to cite you) is much closer to rough consensus. I would be happier to find a total 100% consensus on our work, but if you barricade yourself in your position that would be very very hard to achieve. I was told that standard IETF process is a way how to have things not done and that I am naive to push this through IETF, but I would like to prove them wrong. Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FD33A688B for ; Fri, 20 Aug 2010 07:54:44 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpPalizhnRfJ for ; Fri, 20 Aug 2010 07:54:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 835943A6783 for ; Fri, 20 Aug 2010 07:54:43 -0700 (PDT) Received: from ros-dhcp192-1-51-64.bbn.com ([192.1.51.64]:52677) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmSzz-000ISm-2s; Fri, 20 Aug 2010 10:55:15 -0400 Message-Id: From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Aug 2010 10:55:14 -0400 References: <4C6E5C4B.40904@Dartmouth.edu> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org, Scott Rea Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 14:54:44 -0000 Ah, I have only just now read the initial charter proposal that Warren sent out. I agree that that one is too root-centric. But clearly the problem can be phrased more in terms of application needs (binding keys to domain names) and validation paths (overlaid on DNS) instead of what TAs those paths end in. That's what I tried to do in my earlier proposal. On Aug 20, 2010, at 10:46 AM, Phillip Hallam-Baker wrote: > Plenty of people have asserted that the objective is to do PKI for > 'free'. Others have expressed the opinion that certain services are > 'overpriced'. > > Those are pricing discussions. > > > If you read the other charter proposals you will see that they both > contain statements to the effect that the advantage the group seeks to > realize is to enforce use of a single root of trust. Those are the > parts I find unacceptable. > > > On Fri, Aug 20, 2010 at 10:40 AM, Richard L. Barnes > wrote: >>> If people want to propose a system with a single point of failure >>> then >>> that point of failure has to be on the table for discussion. The >>> only >>> reason I brought ICANN up is that others insisted that we only >>> design >>> a system where the only choice is to trust the ICANN monopoly. >> >> [Citation needed] >> >> >>> I do not think that we want two separate groups, one to do DNSSEC >>> for >>> applications using only the ICANN root and a separate group for >>> applications using a choice of roots. And even if we wanted to, I >>> doubt that a charter of that nature could be accepted by the IESG. >> >> Obviously we don't, because this whole discussion is completely >> unrelated to >> a choice of trust anchors. DNSSEC and other protocols we develop >> in the >> IETF do not require any relying party to use any given trust >> anchor. If you >> want a concrete example, just look at the DLV. >> >> >>> One other charter point. We cannot have any discussion of pricing of >>> products or services (including 'free'). IETF rules have been quite >>> lax on this point to date. However we have to take care not to be >>> the >>> group that brings down the lawyers. >> >> That seems kind of obvious. Who has expressed a desire to discuss >> pricing? >> >> --Richard >> >> >> >> >>> >>> >>> On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea >>> wrote: >>>> >>>> On 8/19/2010 9:16 PM, Paul Hoffman wrote: >>>>> >>>>> At 2:01 AM +0100 8/20/10, Tony Finch wrote: >>>>>> >>>>>> It seems to me from this week's discussion that (exaggerating >>>>>> slightly) >>>>>> no >>>>>> one wants to trust the x.509 certificate authorities and no one >>>>>> wants >>>>>> to >>>>>> trust ICANN's DNSSEC root anchor. >>>>> >>>>> Exaggerating wildly, I would say. Who other than Phill have said >>>>> they >>>>> don't trust ICANN's DNSSEC root anchor? >>>>> >>>>> --Paul Hoffman, Director >>>>> --VPN Consortium >>>>> _______________________________________________ >>>>> keyassure mailing list >>>>> keyassure@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/keyassure >>>> >>>> Hmmm... nothing against ICANN personally, but lots against a >>>> single point >>>> of >>>> failure, I prefer to share that responsibility around >>>> >>>> -- >>>> Scott Rea >>>> Sr PKI Architect (Contractor) >>>> Em: Scott.Rea@Dartmouth.edu >>>> >>>> >>>> _______________________________________________ >>>> keyassure mailing list >>>> keyassure@ietf.org >>>> https://www.ietf.org/mailman/listinfo/keyassure >>>> >>> >>> >>> >>> -- >>> Website: http://hallambaker.com/ >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >> >> > > > > -- > Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8A543A6AA0 for ; Fri, 20 Aug 2010 07:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HffIrdavcekn for ; Fri, 20 Aug 2010 07:46:07 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 75FA93A6A9C for ; Fri, 20 Aug 2010 07:46:07 -0700 (PDT) Received: by ywi4 with SMTP id 4so1307380ywi.31 for ; Fri, 20 Aug 2010 07:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AMPJ2+EudxDNmGGo/3SqhRY5XVF3bGeNJwr+4wIqLYM=; b=cfBu8ClY5Ufw41o+j/EkOqrMdl2q30MJ1NZBHD9mINIadCUsLPddh0wWa9UEyH2Tvc IIqGGNHL9GgjEoliUykzywaPMwvPl6dmKuBgt5aCHPhmEW/99sXt4CCQDmAm54MOyJKS zVYn3osqaG5Pj/FkBxh95XNO2eZVnGV7/x2Sw= 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:content-transfer-encoding; b=K+LiWfv1bsIBOTFLNyczbwYd3lsGRFrR3H+w9SIFwDyWZPa31eHrSHCmEMNWw7ibgY 7T3JrduSgsceuQBTvUjFWlLOt+ogo0pjZhJAMQbFbcsOAiyLtawSBGikz5whW7kC833l vKN5r4Q6LNber9PU150vfg2PMexTUabgrmO6c= MIME-Version: 1.0 Received: by 10.100.121.11 with SMTP id t11mr1756054anc.48.1282315601661; Fri, 20 Aug 2010 07:46:41 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Fri, 20 Aug 2010 07:46:41 -0700 (PDT) In-Reply-To: References: <4C6E5C4B.40904@Dartmouth.edu> Date: Fri, 20 Aug 2010 10:46:41 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org, Scott Rea Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 14:46:09 -0000 Plenty of people have asserted that the objective is to do PKI for 'free'. Others have expressed the opinion that certain services are 'overpriced'. Those are pricing discussions. If you read the other charter proposals you will see that they both contain statements to the effect that the advantage the group seeks to realize is to enforce use of a single root of trust. Those are the parts I find unacceptable. On Fri, Aug 20, 2010 at 10:40 AM, Richard L. Barnes wrote= : >> If people want to propose a system with a single point of failure then >> that point of failure has to be on the table for discussion. The only >> reason I brought ICANN up is that others insisted that we only design >> a system where the only choice is to trust the ICANN monopoly. > > [Citation needed] > > >> I do not think that we want two separate groups, one to do DNSSEC for >> applications using only the ICANN root and a separate group for >> applications using a choice of roots. And even if we wanted to, I >> doubt that a charter of that nature could be accepted by the IESG. > > Obviously we don't, because this whole discussion is completely unrelated= to > a choice of trust anchors. =A0DNSSEC and other protocols we develop in th= e > IETF do not require any relying party to use any given trust anchor. =A0I= f you > want a concrete example, just look at the DLV. > > >> One other charter point. We cannot have any discussion of pricing of >> products or services (including 'free'). IETF rules have been quite >> lax on this point to date. However we have to take care not to be the >> group that brings down the lawyers. > > That seems kind of obvious. =A0Who has expressed a desire to discuss pric= ing? > > --Richard > > > > >> >> >> On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea >> wrote: >>> >>> =A0On 8/19/2010 9:16 PM, Paul Hoffman wrote: >>>> >>>> At 2:01 AM +0100 8/20/10, Tony Finch wrote: >>>>> >>>>> It seems to me from this week's discussion that (exaggerating slightl= y) >>>>> no >>>>> one wants to trust the x.509 certificate authorities and no one wants >>>>> to >>>>> trust ICANN's DNSSEC root anchor. >>>> >>>> Exaggerating wildly, I would say. Who other than Phill have said they >>>> don't trust ICANN's DNSSEC root anchor? >>>> >>>> --Paul Hoffman, Director >>>> --VPN Consortium >>>> _______________________________________________ >>>> keyassure mailing list >>>> keyassure@ietf.org >>>> https://www.ietf.org/mailman/listinfo/keyassure >>> >>> Hmmm... nothing against ICANN personally, but lots against a single poi= nt >>> of >>> failure, I prefer to share that responsibility around >>> >>> -- >>> Scott Rea >>> Sr PKI Architect (Contractor) >>> Em: Scott.Rea@Dartmouth.edu >>> >>> >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >>> >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFA03A67B4 for ; Fri, 20 Aug 2010 07:39:43 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXmDFm31ELSQ for ; Fri, 20 Aug 2010 07:39:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 454B03A67F4 for ; Fri, 20 Aug 2010 07:39:42 -0700 (PDT) Received: from ros-dhcp192-1-51-64.bbn.com ([192.1.51.64]:52381) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmSlM-000I9W-RQ; Fri, 20 Aug 2010 10:40:09 -0400 Message-Id: From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Aug 2010 10:40:08 -0400 References: <4C6E5C4B.40904@Dartmouth.edu> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org, Scott Rea Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 14:39:43 -0000 > If people want to propose a system with a single point of failure then > that point of failure has to be on the table for discussion. The only > reason I brought ICANN up is that others insisted that we only design > a system where the only choice is to trust the ICANN monopoly. [Citation needed] > I do not think that we want two separate groups, one to do DNSSEC for > applications using only the ICANN root and a separate group for > applications using a choice of roots. And even if we wanted to, I > doubt that a charter of that nature could be accepted by the IESG. Obviously we don't, because this whole discussion is completely unrelated to a choice of trust anchors. DNSSEC and other protocols we develop in the IETF do not require any relying party to use any given trust anchor. If you want a concrete example, just look at the DLV. > One other charter point. We cannot have any discussion of pricing of > products or services (including 'free'). IETF rules have been quite > lax on this point to date. However we have to take care not to be the > group that brings down the lawyers. That seems kind of obvious. Who has expressed a desire to discuss pricing? --Richard > > > On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea > wrote: >> On 8/19/2010 9:16 PM, Paul Hoffman wrote: >>> >>> At 2:01 AM +0100 8/20/10, Tony Finch wrote: >>>> >>>> It seems to me from this week's discussion that (exaggerating >>>> slightly) >>>> no >>>> one wants to trust the x.509 certificate authorities and no one >>>> wants to >>>> trust ICANN's DNSSEC root anchor. >>> >>> Exaggerating wildly, I would say. Who other than Phill have said >>> they >>> don't trust ICANN's DNSSEC root anchor? >>> >>> --Paul Hoffman, Director >>> --VPN Consortium >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >> >> Hmmm... nothing against ICANN personally, but lots against a single >> point of >> failure, I prefer to share that responsibility around >> >> -- >> Scott Rea >> Sr PKI Architect (Contractor) >> Em: Scott.Rea@Dartmouth.edu >> >> >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >> > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2984A3A67B4 for ; Fri, 20 Aug 2010 07:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[AWL=1.291, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBcyWhqsOwLf for ; Fri, 20 Aug 2010 07:24:46 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id EE6FC3A68BC for ; Fri, 20 Aug 2010 07:24:45 -0700 (PDT) Received: by gwb20 with SMTP id 20so1452416gwb.31 for ; Fri, 20 Aug 2010 07:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dX7dDq1MN5VYN4P3oVtyJPgYexl9RjNANTvqy3VnDhc=; b=CcDaFsW9mr6D+ywrbZvEUxCtwLKIDiogSA1zmsEW/4N109fM4Li55HGS/sXy2PIvf+ YDNsXEVvbiusBAG1jBPRAmjciXwB21Wsw+X+h8cwhLR7+weOqA0SNurivLtEavVYz7Tc JxHxu6dKDQ7g5v/nP58TpIlHbdjslMVhREIGs= 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:content-transfer-encoding; b=pzHM8sm617Qg0995zwtYjnTw+Z7h4sBK1lO2RYPh0mWv6IpfRkMK3SRWxE28WpdMwl GXJl68hXgv8tbb8mqV5Jh4KXiqzmwywJ5vX5S1SyIibWUQZTP2uoUdFyw3m0SV+Epb6q 16hPU+rV8CKHuV/qZva+mYHZPQzHTajXV4Seg= MIME-Version: 1.0 Received: by 10.151.49.10 with SMTP id b10mr2079709ybk.89.1282314318169; Fri, 20 Aug 2010 07:25:18 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Fri, 20 Aug 2010 07:25:18 -0700 (PDT) In-Reply-To: <4C6E5C4B.40904@Dartmouth.edu> References: <4C6E5C4B.40904@Dartmouth.edu> Date: Fri, 20 Aug 2010 10:25:18 -0400 Message-ID: From: Phillip Hallam-Baker To: Scott Rea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 14:24:47 -0000 That is precisely my position. If people want to propose a system with a single point of failure then that point of failure has to be on the table for discussion. The only reason I brought ICANN up is that others insisted that we only design a system where the only choice is to trust the ICANN monopoly. I do not think that we want two separate groups, one to do DNSSEC for applications using only the ICANN root and a separate group for applications using a choice of roots. And even if we wanted to, I doubt that a charter of that nature could be accepted by the IESG. One other charter point. We cannot have any discussion of pricing of products or services (including 'free'). IETF rules have been quite lax on this point to date. However we have to take care not to be the group that brings down the lawyers. On Fri, Aug 20, 2010 at 6:43 AM, Scott Rea wrote: > =A0On 8/19/2010 9:16 PM, Paul Hoffman wrote: >> >> At 2:01 AM +0100 8/20/10, Tony Finch wrote: >>> >>> It seems to me from this week's discussion that (exaggerating slightly) >>> no >>> one wants to trust the x.509 certificate authorities and no one wants t= o >>> trust ICANN's DNSSEC root anchor. >> >> Exaggerating wildly, I would say. Who other than Phill have said they >> don't trust ICANN's DNSSEC root anchor? >> >> --Paul Hoffman, Director >> --VPN Consortium >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > Hmmm... nothing against ICANN personally, but lots against a single point= of > failure, I prefer to share that responsibility around > > -- > Scott Rea > Sr PKI Architect (Contractor) > Em: Scott.Rea@Dartmouth.edu > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3D3A3A6AAA for ; Fri, 20 Aug 2010 06:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+vmDaDhlJJT for ; Fri, 20 Aug 2010 06:57:33 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 229233A6AA6 for ; Fri, 20 Aug 2010 06:57:33 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 9B9777344D5 for ; Fri, 20 Aug 2010 15:58:06 +0200 (CEST) Message-ID: <4C6E89EE.5010304@nic.cz> Date: Fri, 20 Aug 2010 15:58:06 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <329621.1282251520679.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> <4C6E3BB8.5090707@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 13:57:34 -0000 On 20.8.2010 13:49, Phillip Hallam-Baker wrote: > Seems to me that you are making statements and then ruling objections > to those statements as off topic. You are ripping my words out of the context. I am saying that this is no place to discuss whether we trust "ICANN, Verisign or USG". This group has the proposed charter based on fact that we are going to use DNS and DNSSEC, and we trust it. Again this should be a place where the work is done, and not a chitchat list for discussing whether US companies are good or not. And I ask all participants to respect that. > - Show quoted text - > Exactly. The change of the trust model will be always scary. But it > is important to realize that we don't change overall level of security > (in fact, we are improving it), just the trust model. > > > Ondrej > > On Fri, Aug 20, 2010 at 4:24 AM, Ondřej Surý wrote: >> [moderator hat on] >> This is really off-topic. Please cease a discussion on who to trust. This >> group is to get work done and not to discuss irrelevant topics like this. >> Don't clutter the mailing list, thanks. >> [/moderator hat off] -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8AD43A68AE for ; Fri, 20 Aug 2010 04:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReuOfxUwyklq for ; Fri, 20 Aug 2010 04:55:12 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 926CD3A687C for ; Fri, 20 Aug 2010 04:55:12 -0700 (PDT) Received: by iwn3 with SMTP id 3so3215959iwn.31 for ; Fri, 20 Aug 2010 04:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qy7H+XeJumzf5TXc4n495D2V6H1tmfG5KG3jdLrf4aM=; b=WuWvDqm2n3lhlG0cseVHxHN11S/uj3ODrNCBtiB7BUba3mgGUpnsYvgNou5aUDK8sR ijRGZhnYByABTUoQLRxg63BQguF7x8QcAtTu4Hoei8iTeg/ybKIUVh9tqzNUaHeiuP8+ oSdaWbhfYV6nHyXlmI9cjTTQo1sRWo4MAtGjg= 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:content-transfer-encoding; b=reJC9xgWnW9buaT6Qj88E0UHqIOHZ9JIYflWCSuponagSONaHQiWTgagg9G3RCPANg WCX/c8FgB4uisBVwB4OhNYGmj67CGFrrSzODu9yhtZ2MD7R4o7UV1eItTgtKLkQL9AYh n3aH40du9nmCAw55OipCAwYrNb2WKwsUcQZ24= MIME-Version: 1.0 Received: by 10.231.17.1 with SMTP id q1mr1637218iba.17.1282305347049; Fri, 20 Aug 2010 04:55:47 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Fri, 20 Aug 2010 04:55:46 -0700 (PDT) In-Reply-To: <4C6E3D06.1020406@nic.cz> References: <3C80DCF9-46B6-4714-83F5-1DE5243B93E2@icsi.berkeley.edu> <8A617A03-314E-4007-A792-0DF574CE7143@ICSI.Berkeley.EDU> <9D7CE149-9275-4319-A2C8-890598286DDD@bbn.com> <4C6E3D06.1020406@nic.cz> Date: Fri, 20 Aug 2010 07:55:46 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 11:55:13 -0000 My preference is to rule it out of scope as well. It is possible to use the DNS for purposes other than resolution of names, but that does not mean it is a good idea. On Fri, Aug 20, 2010 at 4:29 AM, Ond=F8ej Sur=FD wrote= : > On 19.8.2010 21:47, Richard L. Barnes wrote: >> >> Depends on what you mean by "system identity", doesn't it? >> >> I tend to take a user-centric view of this. If I type in "ssh 10.1.1.1", >> then the key should be bound to the address, but if I type in "ssh >> example.com", the key should be bound to the name -- I don't care what >> the IP address is as long as the guy at the other end has the right key >> for the domain. >> >> This does raise an interesting question for the group, though: How do we >> want to handle "https://10.1.1.1/" and "https://[fe80::abcd:123]/"? >> Seems like there are two basic possibilities: >> 1. Use the reverse DNS tree >> 2. Declare it out of scope because we're focused authenticating domain >> names >> >> My slight preference is for (2). > > Because of RFC1918 addresses, I tend to prefer (2). > > Ondrej > -- > =A0Ond=F8ej Sur=FD > =A0vedouc=ED v=FDzkumu/Head of R&D department > =A0------------------------------------------- > =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC > =A0Americka 23, 120 00 Praha 2, Czech Republic > =A0mailto:ondrej.sury@nic.cz =A0 =A0http://nic.cz/ > =A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112 > =A0------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49B33A68ED for ; Fri, 20 Aug 2010 04:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFywE34iJu2i for ; Fri, 20 Aug 2010 04:53:08 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 9CC193A68AE for ; Fri, 20 Aug 2010 04:53:08 -0700 (PDT) Received: by ywi4 with SMTP id 4so1216472ywi.31 for ; Fri, 20 Aug 2010 04:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=boh6e9CivhBaVyPC+EQlmuonsBij/xlR/7zRKrEj+Hs=; b=DEdHdxLVAcwEySF1DUHjD8fRIaQWQcya3RTEaVWA529dRM79ilPBnoUkMFFq4gQZ8f vV7YhoUtIZsju5SacFVEdDHD3m+2YuyAWs3dYNUR7/Fb5AWDV9yIxz9OaVs9WcVsIBi9 EWQ6PQbFXC3qpje6RZp3v2jSZxWkh17QdqYfg= 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:content-transfer-encoding; b=fKjlhW1cW3Tjq4iRKdOzE4ivwC/rIBowgiagewyIwM6THFOi4STtBZYj0qb0lwJQlN OgoO2uD3hcFZXvg8Kr5n1NEPgbgkWeWD9SudAkrsGmnEKLdlKwQkxReazAShGhgEz64n Sbsx57+0XkhXdBVlVXBxIXITqN/Nk1CBwMm6Y= MIME-Version: 1.0 Received: by 10.90.95.7 with SMTP id s7mr1022332agb.169.1282305221986; Fri, 20 Aug 2010 04:53:41 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Fri, 20 Aug 2010 04:53:41 -0700 (PDT) In-Reply-To: <4C6E3B2E.9040205@nic.cz> References: <50A38D0D-8F66-4A8B-836A-9C8A5C0F9280@bbn.com> <4C6E3B2E.9040205@nic.cz> Date: Fri, 20 Aug 2010 07:53:41 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 11:53:09 -0000 We definitely should not write that protocol here. Hence I wrote 'at a high level'. But we should not paint ourselves into a corner here and adopt unrealistic assumptions that preclude that type of approach. Limiting services to a single shared key is bad crypto hygiene and harder to manage. There is no advantage to doing so. On Fri, Aug 20, 2010 at 4:22 AM, Ond=F8ej Sur=FD wrote= : > On 19.8.2010 19:30, Richard L. Barnes wrote: >>>> >>>> At a high level, what I would like to see here is a mechanism that >>>> allows an application to generate a key pair and request registration >>>> in the DNS as part of the install package. >>> >>> Dynamic DNS updates ought to be part of the solution, though I don't kn= ow >>> how to make it easier to manage the trust relationship (i.e. the nsupda= te >>> keys) between the DNS admin and the app admins. >> >> I would say that this sort of provisioning information should be out of >> the scope of the working group. Standard DNS provisioning techniques >> apply. > > Ack. =A0I don't see a reason why we should do anything with DNS provision= ing. > =A0(If anybody is willing to write BCP, he could, but I don't see a reaso= n for > that.) > > Ondrej > -- > =A0Ond=F8ej Sur=FD > =A0vedouc=ED v=FDzkumu/Head of R&D department > =A0------------------------------------------- > =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC > =A0Americka 23, 120 00 Praha 2, Czech Republic > =A0mailto:ondrej.sury@nic.cz =A0 =A0http://nic.cz/ > =A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112 > =A0------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D6B3A68EC for ; Fri, 20 Aug 2010 04:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.452 X-Spam-Level: X-Spam-Status: No, score=-1.452 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4aihqS0k9ZI for ; Fri, 20 Aug 2010 04:46:45 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 9548B3A6A8F for ; Fri, 20 Aug 2010 04:46:45 -0700 (PDT) Received: by iwn3 with SMTP id 3so3207605iwn.31 for ; Fri, 20 Aug 2010 04:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dZuA6Zlg4NdT14NwS+Il9o3NcwyR0s7dNjnvj3rQ004=; b=o/RM3YAiP9/omnYkwWCygkvPErPv5acZvASw8Eacc6T3ebtIbhKIaubGHBG4gt+yRZ L7yaT46gkG0o9Nep75QpQ7bqrsfdBOftgtSQTIKWEcrbl0pa0BbSI8mLWdhujocdS/Un 2iLstqzCAGVoejk80vgMJJk2SXe2OVJAsfyZQ= 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:content-transfer-encoding; b=fnS6Le7e9vEdT3DZGrfBD0O23PH8pYEUPllERVIQ/lHRHOAr2AcQ21pJoN3nMLVVPB DHKrsKtbjwWd6GiTo/ehYBx2zenYUBBsjnFFVpFFciXutcsKuS64BT9aPRny/rJb8d12 aU9JIrYgm/WPWMHatCWmdOutdxcMv/WJ/jojo= MIME-Version: 1.0 Received: by 10.231.190.10 with SMTP id dg10mr1638390ibb.46.1282304839701; Fri, 20 Aug 2010 04:47:19 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Fri, 20 Aug 2010 04:47:19 -0700 (PDT) In-Reply-To: <4C6E393F.1060909@nic.cz> References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> <25610D95-3C55-4920-B33B-B420E8CF639B@gmail.com> <4C6E393F.1060909@nic.cz> Date: Fri, 20 Aug 2010 07:47:19 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 11:46:47 -0000 There will be no change in the trust model. You are adding in one additional root. You are not going to remove the others. The IETF is very likely to charter a group that is going to look at the problem of how to enable applications to use DNSSEC. But I think it highly unlikely that they would charter a group to engineer a change in the trust model from a market based solution to a monopoly. That just is not going to happen. On Fri, Aug 20, 2010 at 4:13 AM, Ond=F8ej Sur=FD wrote= : > On 20.8.2010 00:04, Warren Kumari wrote: >> >> On Aug 19, 2010, at 12:40 PM, Stephen Schultze wrote: >> >>> David said basically what I was going to say on your other points, but >>> I wanted to also note the following: >>> >>> On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote: >>>> >>>> The point you are still not getting here is that the security of the >>>> system is measured from the point of view of the relying party. The >>>> relying party does not choose either the CA or the Registrar, but an >>>> attacker can. >>> >>> >>> Let's describe the assurances that the relying party has in each case: >>> >>> Standard CA DV cert: >>> One of thousands of entities with cert-issuing authority said that the >>> holder of the corresponding private key controls the zone for the >>> domain in question. There may be other people out there who also have >>> certificates that assert that they control the domain, but neither you >>> nor this issuing CA necessarily know if they exist. Every root CA has >>> equivalent authority as far as you're concerned, and an attacker can >>> choose the lowest common denominator CA and serve you those certs at >>> will. >>> >>> DNSSEC domain-key assertion: >>> The person who controls the zone for the domain in question holds the >>> corresponding private key. The only opportunity for mischief or >>> mistake is in the one single path that the zone controller chose: >>> their nameserver (especially if they are doing online signing), the >>> registrar, the registry, and the root (and if there are DS records for >>> sub-domains, whoever controls those). What's more, any substitution of >>> a baddie's DS record for the true domain owner's DS record would be >>> highly visible and likely to be immediately corrected. >> >> So, when I initially started looking at all this (leveraging the DNSSEC >> TA as a TA for other things) I thought that it was the best thing since >> sliced bread... until it occurred to me that this was changing who all >> could muck with your security. >> CA certs were handed out by CAs, and you didn't need to worry about >> being attacked by your (probably outsourced) DNS provider, your >> (probably reseller) registrar, their parent registrar and the registry >> (or, more likely, the chappie who owned your nameserver because you >> thought that 'P@ssword' was a good choice). I ended up rewriting my >> initial draft saying that the only use for this was to allow you to >> attest to what the *correct* CA issued cert was, and apologized to the >> folk to whom I had given the original drafts to for wasting their time..= . >> A long set of emails and phonecalls and IMs then occurred, with me >> kvetching about how this was changing the fundamental trust model, and >> opening you up to dinking with by all of the folk in the registration / >> DNS side of things and how the sky was falling... but, for every >> scenario that I came up with (rogue DNS provider, hacked nameserver, bad >> registrar) folk convinced me that the attackers could just as easily >> redirect my MX record and use that to obtain a CA signed cert... It took >> some time (I guess because I didn't want to admit to myself just how >> screwed we were), but they have fully convinced me -- once someone in a >> position to change your DNS responses (by inserting DNSSEC signed >> keymaterial or something) they are in a position to get a cert.... > > Exactly. =A0The change of the trust model will be always scary. =A0But it= is > important to realize that we don't change overall level of security (in > fact, we are improving it), just the trust model. > > Ondrej > -- > =A0Ond=F8ej Sur=FD > =A0vedouc=ED v=FDzkumu/Head of R&D department > =A0------------------------------------------- > =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC > =A0Americka 23, 120 00 Praha 2, Czech Republic > =A0mailto:ondrej.sury@nic.cz =A0 =A0http://nic.cz/ > =A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112 > =A0------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD61F3A68E9 for ; Fri, 20 Aug 2010 03:43:30 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRi71jUJ5tUw for ; Fri, 20 Aug 2010 03:43:30 -0700 (PDT) Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by core3.amsl.com (Postfix) with ESMTP id D2AAE3A6822 for ; Fri, 20 Aug 2010 03:43:29 -0700 (PDT) Received: from newdasher.Dartmouth.EDU (newdasher.dartmouth.edu [129.170.208.30]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id o7KAKqdv015446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Aug 2010 06:43:55 -0400 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from c-66-31-140-162.hsd1.nh.comcast.net [66.31.140.162] by newdasher.Dartmouth.EDU (Mac) via SMTP for keyassure@ietf.org id <174640767>; 20 Aug 2010 06:43:55 -0400 Message-ID: <4C6E5C4B.40904@Dartmouth.edu> Date: Fri, 20 Aug 2010 06:43:23 -0400 From: Scott Rea User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean by mailhub2.dartmouth.edu X-MailScanner-From: scott.rea@dartmouth.edu X-Mailman-Approved-At: Fri, 20 Aug 2010 06:42:54 -0700 Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 10:43:31 -0000 On 8/19/2010 9:16 PM, Paul Hoffman wrote: > At 2:01 AM +0100 8/20/10, Tony Finch wrote: >> It seems to me from this week's discussion that (exaggerating slightly) no >> one wants to trust the x.509 certificate authorities and no one wants to >> trust ICANN's DNSSEC root anchor. > Exaggerating wildly, I would say. Who other than Phill have said they don't trust ICANN's DNSSEC root anchor? > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Hmmm... nothing against ICANN personally, but lots against a single point of failure, I prefer to share that responsibility around -- Scott Rea Sr PKI Architect (Contractor) Em: Scott.Rea@Dartmouth.edu Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11873A69EC for ; Fri, 20 Aug 2010 02:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.677 X-Spam-Level: X-Spam-Status: No, score=-104.677 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jan2D9-Lb3+8 for ; Fri, 20 Aug 2010 02:28:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C3F703A67E1 for ; Fri, 20 Aug 2010 02:28:27 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o7K9T1bE007906 for ; Fri, 20 Aug 2010 02:29:01 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282296542; bh=nt0WrvDZDuoVs9O+zS/hnbuKmAk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=g112TKpNKCTXHr2QG79GQ/Ju55aplQ4JfL44ue8s8gzUXq3gYoTaHC6akBcvb35F7 1h7d0SA5ujvqqvg8+LOMg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=ywXHuPN8IN//FHQcv4VHimY3KI7M3Av4h8Qu8rNMNDxBhH/DhKCrv5YXQ6OKxPH+H Gmlb5wAXiVncE38N9SUPA== Received: from vws5 (vws5.prod.google.com [10.241.21.133]) by kpbe19.cbf.corp.google.com with ESMTP id o7K9T0Yh023081 for ; Fri, 20 Aug 2010 02:29:00 -0700 Received: by vws5 with SMTP id 5so3007085vws.23 for ; Fri, 20 Aug 2010 02:29:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.127.4 with SMTP id e4mr645418vcs.235.1282296540054; Fri, 20 Aug 2010 02:29:00 -0700 (PDT) Received: by 10.220.58.137 with HTTP; Fri, 20 Aug 2010 02:29:00 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Aug 2010 10:29:00 +0100 Message-ID: From: Ben Laurie To: Tony Finch Content-Type: multipart/alternative; boundary=001636e1ef9dc4447b048e3ded3e X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 09:28:29 -0000 --001636e1ef9dc4447b048e3ded3e Content-Type: text/plain; charset=ISO-8859-1 On 19 August 2010 18:08, Tony Finch wrote: > Paul Wouters wrote: > >On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote: > >> > >> In my view user keys do not belong in the DNS because the DNS is an > >> infrastructure for locating network services, not network users. > > > > I disagree. You are locating an identity. Currently, that is mostly done > > based on an IP address and port. I'd hope tomorrow that would mostly be > > done based on a public key or hash. Especially with mobile devices, IP's > > are very volatile. To locate a service or user, we need the DNS. > > Yes. At the moment the PKIs for identifying people are rather cumbersome. > It would be nice to be able to use DNSSEC for verifying S/MIME or PGP > messages. > Webfinger seems like a better vehicle for this kind of thing (probably combined with some DNSSEC for key bootstrapping). > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --001636e1ef9dc4447b048e3ded3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 19 August 2010 18:08, Tony Finch <dot@dotat.at> wrote:
Paul Wouters <paul@xelerance.com> wrote:
>On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote:
>>
>> In my view user keys do not belong in the DNS because the DNS is a= n
>> infrastructure for locating network services, not network users. >
> I disagree. You are locating an identity. Currently, that is mostly do= ne
> based on an IP address and port. I'd hope tomorrow that would most= ly be
> done based on a public key or hash. Especially with mobile devices, IP= 's
> are very volatile. To locate a service or user, we need the DNS.

Yes. At the moment the PKIs for identifying people are rather cumbersome. It would be nice to be able to use DNSSEC for verifying S/MIME or PGP
messages.


Tony.
--
f.anthony.n.finch =A0<dot@dotat.at&g= t; =A0http://dotat.at/ SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD.<= br> _______________________________________________
keyassure mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure

--001636e1ef9dc4447b048e3ded3e-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9133A68F3 for ; Fri, 20 Aug 2010 02:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uZjOcBYrADF for ; Fri, 20 Aug 2010 02:11:35 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 056583A6A86 for ; Fri, 20 Aug 2010 02:09:22 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 089DA734271 for ; Fri, 20 Aug 2010 11:09:56 +0200 (CEST) Message-ID: <4C6E4663.6@nic.cz> Date: Fri, 20 Aug 2010 11:09:55 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <185111DC-53F3-4DB0-A00B-185F30EF3493@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 09:11:37 -0000 On 19.8.2010 19:35, Paul Hoffman wrote: > At 1:22 PM -0400 8/19/10, Richard L. Barnes wrote: >> This seems like a bad path to be headed down. There are lots of >> identifiers that can be tied to public keys: email addresses, SIP >> URIs, telephone numbers, childhood nicknames. It would be a >> mistake to try to smash them all into the DNS. > > +1. The DNS is good for giving information that is related to domain > names, not all the users of the things at the domain names. As Jakob already said. RFC 4398 Section 3.2 for X.509 (and 3.3 for OpenPGP) states the coding of email address into a domain name. We don't have to solve all the identifiers. We could do that just for email address. But I certainly don't want to mangle all together in this (non-)WG. BTW is there any work? RFC 4398 is already there. Does it miss something important which cannot be used for S/MIME, OpenPGP? Or is this just an non-existent implementation issue? Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0D143A682F for ; Fri, 20 Aug 2010 01:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vX1VtRIQdaci for ; Fri, 20 Aug 2010 01:58:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 5E1303A6824 for ; Fri, 20 Aug 2010 01:58:09 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 38A3A734271 for ; Fri, 20 Aug 2010 10:58:43 +0200 (CEST) Message-ID: <4C6E43C2.2050408@nic.cz> Date: Fri, 20 Aug 2010 10:58:42 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 08:58:12 -0000 On 19.8.2010 19:25, Phillip Hallam-Baker wrote: > I agree it would be nice to use DNSSEC in the validation path. > > But the problem is that the DNS management is typically under control > of people responsible for managing machines and not people. > > We have a spec for putting certs onto a Web server and pulling them via HTTP. > > > oops, just saw a can of worms here. If we are not careful with our > validation scheme, we will end up in a situation where people can use > the S/MIME cert they were issued (e.g. fred@bigbank.com) to set up a > Web Server (https://bigbank.com/) The would be a very bad specification. However we already have a mechanism for coding a email into a domain identifier. Remember the SOA record? :) So we could specify that fred@bigbank.com becomes fred.bigbank.com and ondrej.sury@nic.cz becomes ondrej\.sury.nic.cz Also the information in the DNS has to be DNSSEC validated, so how would fred@bigbank.com be able to put the information into DNS? And if we assume tight control over DNS, we could maybe specify something like "usage" flag? Or entirely new RR type, so: bigbank.com TLSFP .... fred.bigbank.com SMIMEFP ... Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8423A68E8 for ; Fri, 20 Aug 2010 01:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yZfGG-Cg7wB for ; Fri, 20 Aug 2010 01:29:25 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id CBD283A6821 for ; Fri, 20 Aug 2010 01:29:24 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id A520F7343B3 for ; Fri, 20 Aug 2010 10:29:58 +0200 (CEST) Message-ID: <4C6E3D06.1020406@nic.cz> Date: Fri, 20 Aug 2010 10:29:58 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <3C80DCF9-46B6-4714-83F5-1DE5243B93E2@icsi.berkeley.edu> <8A617A03-314E-4007-A792-0DF574CE7143@ICSI.Berkeley.EDU> <9D7CE149-9275-4319-A2C8-890598286DDD@bbn.com> In-Reply-To: <9D7CE149-9275-4319-A2C8-890598286DDD@bbn.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 08:29:26 -0000 On 19.8.2010 21:47, Richard L. Barnes wrote: > Depends on what you mean by "system identity", doesn't it? > > I tend to take a user-centric view of this. If I type in "ssh 10.1.1.1", > then the key should be bound to the address, but if I type in "ssh > example.com", the key should be bound to the name -- I don't care what > the IP address is as long as the guy at the other end has the right key > for the domain. > > This does raise an interesting question for the group, though: How do we > want to handle "https://10.1.1.1/" and "https://[fe80::abcd:123]/"? > Seems like there are two basic possibilities: > 1. Use the reverse DNS tree > 2. Declare it out of scope because we're focused authenticating domain > names > > My slight preference is for (2). Because of RFC1918 addresses, I tend to prefer (2). Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9633A6843 for ; Fri, 20 Aug 2010 01:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqYvDt1Us5TI for ; Fri, 20 Aug 2010 01:23:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id EFF973A67E5 for ; Fri, 20 Aug 2010 01:23:50 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id C263973439F for ; Fri, 20 Aug 2010 10:24:24 +0200 (CEST) Message-ID: <4C6E3BB8.5090707@nic.cz> Date: Fri, 20 Aug 2010 10:24:24 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <329621.1282251520679.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> In-Reply-To: <329621.1282251520679.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 08:23:53 -0000 [moderator hat on] This is really off-topic. Please cease a discussion on who to trust. This group is to get work done and not to discuss irrelevant topics like this. Don't clutter the mailing list, thanks. [/moderator hat off] On 19.8.2010 22:58, Jeffrey A. Williams wrote: > David and all, > > The choices for whom to trust are: Verisign, ICANN, or the > USG. Well that's a poor group to pick from according to > many folks, eh Dave?>;) As most americans know the trust > in their government is at a nearly 70 year low, Trust in ICANN > has ebbed and flowed but is nearly as low, and Verisign all > be they have good folks there, seems to be the default remaining > choice. Seems like a logical deduction choice that leaves > in some folks mind and experiance, not very good choices. > > We need more choices OR we need better choices, take your > pick. The 'Truste Anchors' approach in DNSSEC gives a few > more, but perhaps not enough OR not the 'Right' ones to choose > from? > > > -----Original Message----- >> From: David Conrad >> Sent: Aug 18, 2010 10:42 PM >> To: Phillip Hallam-Baker >> Cc: keyassure@ietf.org >> Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications >> >> On Aug 18, 2010, at 7:26 PM, Phillip Hallam-Baker wrote: >>> I want to use dnssec without the ICANN root. >> >> Feel free. There are (currently) only about 300 TLD trust anchors you'll have to keep track of if all the TLDs started signing. ICANN says they'll be adding no more than about 1000/year. You'll have to figure out a way of securely fetching the trust anchors from the TLD admins who sign their zones to install into your validating resolver, but that's a minor detail. >> >> A single root of trust _can be_ better since there are less parties to vet and audit (1 versus many). However, as I said, if you don't want to trust ICANN, VeriSign, and the US Government, you don't have to. >> >> Regards, >> -drc >> >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > Regards, > > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > > "Credit should go with the performance of duty and not with what is very > often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; liability > depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of > Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com > Phone: 214-244-4827 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D063A6843 for ; Fri, 20 Aug 2010 01:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kES2khVVUmog for ; Fri, 20 Aug 2010 01:21:35 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 8F1423A683C for ; Fri, 20 Aug 2010 01:21:32 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 6DFA273439F for ; Fri, 20 Aug 2010 10:22:06 +0200 (CEST) Message-ID: <4C6E3B2E.9040205@nic.cz> Date: Fri, 20 Aug 2010 10:22:06 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <50A38D0D-8F66-4A8B-836A-9C8A5C0F9280@bbn.com> In-Reply-To: <50A38D0D-8F66-4A8B-836A-9C8A5C0F9280@bbn.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 08:21:36 -0000 On 19.8.2010 19:30, Richard L. Barnes wrote: >>> At a high level, what I would like to see here is a mechanism that >>> allows an application to generate a key pair and request registration >>> in the DNS as part of the install package. >> >> Dynamic DNS updates ought to be part of the solution, though I don't know >> how to make it easier to manage the trust relationship (i.e. the nsupdate >> keys) between the DNS admin and the app admins. > > I would say that this sort of provisioning information should be out of > the scope of the working group. Standard DNS provisioning techniques apply. Ack. I don't see a reason why we should do anything with DNS provisioning. (If anybody is willing to write BCP, he could, but I don't see a reason for that.) Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E870F3A67E5 for ; Fri, 20 Aug 2010 01:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nq18Cm8J-aS3 for ; Fri, 20 Aug 2010 01:13:20 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 588023A67B7 for ; Fri, 20 Aug 2010 01:13:18 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id DD47773439F for ; Fri, 20 Aug 2010 10:13:51 +0200 (CEST) Message-ID: <4C6E393F.1060909@nic.cz> Date: Fri, 20 Aug 2010 10:13:51 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> <25610D95-3C55-4920-B33B-B420E8CF639B@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 08:13:22 -0000 On 20.8.2010 00:04, Warren Kumari wrote: > > On Aug 19, 2010, at 12:40 PM, Stephen Schultze wrote: > >> David said basically what I was going to say on your other points, but >> I wanted to also note the following: >> >> On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote: >>> The point you are still not getting here is that the security of the >>> system is measured from the point of view of the relying party. The >>> relying party does not choose either the CA or the Registrar, but an >>> attacker can. >> >> >> Let's describe the assurances that the relying party has in each case: >> >> Standard CA DV cert: >> One of thousands of entities with cert-issuing authority said that the >> holder of the corresponding private key controls the zone for the >> domain in question. There may be other people out there who also have >> certificates that assert that they control the domain, but neither you >> nor this issuing CA necessarily know if they exist. Every root CA has >> equivalent authority as far as you're concerned, and an attacker can >> choose the lowest common denominator CA and serve you those certs at >> will. >> >> DNSSEC domain-key assertion: >> The person who controls the zone for the domain in question holds the >> corresponding private key. The only opportunity for mischief or >> mistake is in the one single path that the zone controller chose: >> their nameserver (especially if they are doing online signing), the >> registrar, the registry, and the root (and if there are DS records for >> sub-domains, whoever controls those). What's more, any substitution of >> a baddie's DS record for the true domain owner's DS record would be >> highly visible and likely to be immediately corrected. > > So, when I initially started looking at all this (leveraging the DNSSEC > TA as a TA for other things) I thought that it was the best thing since > sliced bread... until it occurred to me that this was changing who all > could muck with your security. > CA certs were handed out by CAs, and you didn't need to worry about > being attacked by your (probably outsourced) DNS provider, your > (probably reseller) registrar, their parent registrar and the registry > (or, more likely, the chappie who owned your nameserver because you > thought that 'P@ssword' was a good choice). I ended up rewriting my > initial draft saying that the only use for this was to allow you to > attest to what the *correct* CA issued cert was, and apologized to the > folk to whom I had given the original drafts to for wasting their time... > A long set of emails and phonecalls and IMs then occurred, with me > kvetching about how this was changing the fundamental trust model, and > opening you up to dinking with by all of the folk in the registration / > DNS side of things and how the sky was falling... but, for every > scenario that I came up with (rogue DNS provider, hacked nameserver, bad > registrar) folk convinced me that the attackers could just as easily > redirect my MX record and use that to obtain a CA signed cert... It took > some time (I guess because I didn't want to admit to myself just how > screwed we were), but they have fully convinced me -- once someone in a > position to change your DNS responses (by inserting DNSSEC signed > keymaterial or something) they are in a position to get a cert.... Exactly. The change of the trust model will be always scary. But it is important to realize that we don't change overall level of security (in fact, we are improving it), just the trust model. Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F263A6858 for ; Thu, 19 Aug 2010 22:24:49 -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_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aBo0vx4bgZ4 for ; Thu, 19 Aug 2010 22:24:47 -0700 (PDT) Received: from mail.kirei.se (wagaya.kirei.se [91.206.174.10]) by core3.amsl.com (Postfix) with ESMTP id 76F763A6A40 for ; Thu, 19 Aug 2010 22:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kirei.se; s=wagaya20060620; t=1282281917; bh=LSB+u+txgHD3MLTqBALC7uHgl/PPuED+SoC1dVgG7CI=; h=Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=UrN3fbcj4nXo6EIWb7jBRmcy+1r6chPtBOYJbsYtNLoCl5gSVnHZxfTY9HuH6iRGP 3Ee0WmOIGIHJJgJLgNnCG6L7u9s7UOSMKsIu1r6Mk3ggIcy+vKi2pFWaIPuZnHtkq0 dAjQ4VgubCksPrw6nBYTMHALSzmcPRXGoi6bry2c= Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Fri, 20 Aug 2010 07:25:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9ADBADAC-B614-4E34-B195-D38DE16B491B@kirei.se> References: <8DD78B60-BA3E-4408-BDBA-AC65F981C84C@kirei.se> <157B8B25-72DE-4A98-BDD9-4606E78D55C5@gmail.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 05:24:49 -0000 On 20 aug 2010, at 03.24, Phillip Hallam-Baker wrote: > People asked me to justify the design proposal I made, so I did. >=20 > In the case of SSL the answer is twofold >=20 > 1) The full cert is passed in the protocol in any case. > 2) Having a separate record bound to a specific protocol means we can > have statements of the form 'SSL is always offered'. while this thread is about 'user keys', I'm not sure how SSL is ready = applicable (unless you talk about client certificates). for user keys, = and as already mentioned, the CERT RR has support for indirect = information, including URLs of X.509 data objects and OpenPGP packets. jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BC4B3A6781 for ; Thu, 19 Aug 2010 20:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NGUVbjSsj5D for ; Thu, 19 Aug 2010 20:27:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3FB373A635F for ; Thu, 19 Aug 2010 20:27:04 -0700 (PDT) Received: from [128.89.253.246] (port=50438 helo=[192.168.1.43]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmIGY-0009nI-Eq; Thu, 19 Aug 2010 23:27:38 -0400 Message-Id: From: "Richard L. Barnes" To: Paul Hoffman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 23:27:37 -0400 References: X-Mailer: Apple Mail (2.936) Cc: Tony Finch , keyassure@ietf.org Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 03:27:05 -0000 +1 All this trust anchor discussion is really irrelevant to protocol design. We just make the chains, the relying parties choose what trust anchors to hang them from. --Richard On Aug 19, 2010, at 9:16 PM, Paul Hoffman wrote: > At 2:01 AM +0100 8/20/10, Tony Finch wrote: >> It seems to me from this week's discussion that (exaggerating >> slightly) no >> one wants to trust the x.509 certificate authorities and no one >> wants to >> trust ICANN's DNSSEC root anchor. > > Exaggerating wildly, I would say. Who other than Phill have said > they don't trust ICANN's DNSSEC root anchor? > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD133A6A1F for ; Thu, 19 Aug 2010 18:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUJF8i-99iOJ for ; Thu, 19 Aug 2010 18:23:29 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 5324A3A69FE for ; Thu, 19 Aug 2010 18:23:28 -0700 (PDT) Received: by iwn3 with SMTP id 3so2640460iwn.31 for ; Thu, 19 Aug 2010 18:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0vOE1NGkjHbKdv9qOYKMp/itrWIktMwPq+G/WYj4i4U=; b=EhTuVvno63I4jeJf1Lb9Zk4It6m/cwRCs2hfiOFTjuoQajmB0bJxJ8eTA2bdhdXJMm RGYJpcyNc6aL+ze0Yw3jQFGyU5UHUcUEB2T9CEjuDOXseEHeVxLgP7caOPk3iak63Whb 2RLULaxn9asmzdm8r9WGxRVBkHMov0xkiIB7A= 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:content-transfer-encoding; b=Y7yi82GhIZjabcutROODgKkE4l7LA0BY8uTY8aXaeTZ5+qjIOBBRIeOQecb5Kox4lr EvQLVQPNCkXYaXJfxQ8gBIn2Lvxo6J7WQ37CD/jahIqiHmhbnfxInQERHoagyKigXtza M9KX4T5V8iocSqEm4KspqUkCKtEP9kZczgYDw= MIME-Version: 1.0 Received: by 10.231.34.70 with SMTP id k6mr810278ibd.25.1282267443269; Thu, 19 Aug 2010 18:24:03 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 19 Aug 2010 18:24:03 -0700 (PDT) In-Reply-To: References: <8DD78B60-BA3E-4408-BDBA-AC65F981C84C@kirei.se> <157B8B25-72DE-4A98-BDD9-4606E78D55C5@gmail.com> Date: Thu, 19 Aug 2010 21:24:03 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 01:23:35 -0000 People asked me to justify the design proposal I made, so I did. In the case of SSL the answer is twofold 1) The full cert is passed in the protocol in any case. 2) Having a separate record bound to a specific protocol means we can have statements of the form 'SSL is always offered'. Now the thing about the cert size is why it has not been done that way in the past. Whether it is a valid reason or not, it is a reason. A cert signed with RSA 2048 for a RSA 2048 key is going to have 512 bytes of just the signature data. And an RSA 4096 cert is going to be 1K which is pushing the ethernet MTU with fairly minimal X.509 gubbins. I don't see the transport issue on following a URL, if the hash is in the DNS we have accreditation for the bits. No further bootstrapping is necessary. There are some minor additional advantages to hashes over raw certs, one is that hashes leak less information. Though why that is an advantage I am not sure. Of course this is all reinventing the wheel that many of us have proposed before. I wrote a chapter in my book proposing a similar scheme. There is also DKIM and there was the FREESWAN work. We all seem to be in violent agreement on this specific point. A new record with the hash algorithm and hash value with an optional URL field seems to work for most people here. It also has the advantage that it does not tie us to X.509 certs. The X.509 certs are clearly optimal for SSL because that is what it is designed to use. They may not be optimal for other applications/protocols. On Thu, Aug 19, 2010 at 9:03 PM, Paul Hoffman wrote= : > At 7:52 PM -0400 8/19/10, Phillip Hallam-Baker wrote: >>Main problem I have heard is that certs tend to be quite large in dns ter= ms > > First off, there have been many earlier threads on DNSEXT about this. If = you are saying "I agree with the few people who think this is a problem", t= hat's fine, but it is not widely-agreed to. I do not believe that this mail= ing list is a good place to recreate that debate without all the DNS mafia = here to chime in. > > Secondly, you don't have to use certs in the CERT RR. For example, see ou= r proposal in our draft. > >>I was thinking of using a URL to retrieve the cert if that was necessary.= Then you can get the trust path as well - if your app needs that. > > This is re-inventing what we did in IKEv2bis, and you have the chicken-an= d-egg problem of needing to have secure transport of certificate after gett= ing the URL securely. > > Really, this has all been discussed and written down before. > > At 4:56 PM -0700 8/19/10, Nicholas Weaver wrote: >>However, keeping certs is arguably unnecessary: just a hash of a cert acc= omplishes the same thing in pretty much any existing cryptographic protocol= . > > Exactly. > > --Paul Hoffman, Director > --VPN Consortium > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABA6E3A6995 for ; Thu, 19 Aug 2010 18:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.771 X-Spam-Level: X-Spam-Status: No, score=-99.771 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2i88nXyuIc5L for ; Thu, 19 Aug 2010 18:15:36 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id DD9493A693B for ; Thu, 19 Aug 2010 18:15:36 -0700 (PDT) Received: from [10.20.30.158] (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 o7K1G65v018761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 18:16:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 19 Aug 2010 18:16:04 -0700 To: Tony Finch , keyassure@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 01:15:37 -0000 At 2:01 AM +0100 8/20/10, Tony Finch wrote: >It seems to me from this week's discussion that (exaggerating slightly) no >one wants to trust the x.509 certificate authorities and no one wants to >trust ICANN's DNSSEC root anchor. Exaggerating wildly, I would say. Who other than Phill have said they don't trust ICANN's DNSSEC root anchor? --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3683A69FE for ; Thu, 19 Aug 2010 18:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.867 X-Spam-Level: X-Spam-Status: No, score=-99.867 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FK482WG8gwf for ; Thu, 19 Aug 2010 18:02:41 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 8E2BB3A67C3 for ; Thu, 19 Aug 2010 18:02:41 -0700 (PDT) Received: from [10.20.30.158] (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 o7K13DbU018144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 18:03:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <157B8B25-72DE-4A98-BDD9-4606E78D55C5@gmail.com> References: <8DD78B60-BA3E-4408-BDBA-AC65F981C84C@kirei.se> <157B8B25-72DE-4A98-BDD9-4606E78D55C5@gmail.com> Date: Thu, 19 Aug 2010 18:03:02 -0700 To: Phillip Hallam-Baker From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 01:02:43 -0000 At 7:52 PM -0400 8/19/10, Phillip Hallam-Baker wrote: >Main problem I have heard is that certs tend to be quite large in dns terms First off, there have been many earlier threads on DNSEXT about this. If you are saying "I agree with the few people who think this is a problem", that's fine, but it is not widely-agreed to. I do not believe that this mailing list is a good place to recreate that debate without all the DNS mafia here to chime in. Secondly, you don't have to use certs in the CERT RR. For example, see our proposal in our draft. >I was thinking of using a URL to retrieve the cert if that was necessary. Then you can get the trust path as well - if your app needs that. This is re-inventing what we did in IKEv2bis, and you have the chicken-and-egg problem of needing to have secure transport of certificate after getting the URL securely. Really, this has all been discussed and written down before. At 4:56 PM -0700 8/19/10, Nicholas Weaver wrote: >However, keeping certs is arguably unnecessary: just a hash of a cert accomplishes the same thing in pretty much any existing cryptographic protocol. Exactly. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4448C3A69FE for ; Thu, 19 Aug 2010 18:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[AWL=1.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3Bz3QhniQGZ for ; Thu, 19 Aug 2010 18:00:32 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) by core3.amsl.com (Postfix) with ESMTP id E905D3A67C3 for ; Thu, 19 Aug 2010 18:00:31 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:56669) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1OmFyj-00024l-iV (Exim 4.72) for keyassure@ietf.org (return-path ); Fri, 20 Aug 2010 02:01:05 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OmFyj-0000G2-PL (Exim 4.67) for keyassure@ietf.org (return-path ); Fri, 20 Aug 2010 02:01:05 +0100 Date: Fri, 20 Aug 2010 02:01:05 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: keyassure@ietf.org Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [keyassure] who to trust X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 01:00:33 -0000 It seems to me from this week's discussion that (exaggerating slightly) no one wants to trust the x.509 certificate authorities and no one wants to trust ICANN's DNSSEC root anchor. So how can users decouple their trust anchors for their important applications (banking! email!) from third parties that they don't want to trust very much? At the moment most crypto implementations have one of two models (ignoring weird geeky outliers): (a) Stateless trusted third party. Like SSL / X.509. Forget any past interactions with the service, all you care about is whether its certificate is signed with any of innumerable minimally trustworthy third parties. (b) Static trust anchor configuration, established manually or with a semi-manual ssh-style leap of faith. Any disagreement is an attack. Neither of these support key rollover properly. In case (a) a client cannot tell the difference between a key rollover and an exploit against an untrustworthy CA. In case (b) a key rollover is a festival of exciting warnings, just like a man-in-the-middle attack. There is a better solution between these extremes, where a chain of signatures maintains trust across key rollovers. This model is used with more or less automation by RFC 5011 and PGP. It means you only need to trust third parties to establish initial authentication, after which your ongoing relationship with the second party maintains that authentication. So perhaps this group should see its job as providing another way (alongside x.509 / pgp / etc) of authenticating an initial introduction to a service, or of re-establishing authentication after a hiatus. After that introduction apps should maintain an independent trust relationship. The fact that apps do not maintain trust relationships across key rollovers in this way is a very important problem. I do not think this group is the right one to solve it. Tony. -- f.anthony.n.finch http://dotat.at/ PORTLAND PLYMOUTH NORTH BISCAY: SOUTHERLY OR SOUTHWESTERLY 5 TO 7. MODERATE OR ROUGH. RAIN OR DRIZZLE. MODERATE OR POOR. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B853A67F3 for ; Thu, 19 Aug 2010 17:57:18 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gkXln14L+Us for ; Thu, 19 Aug 2010 17:57:17 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 0DEEB3A67C3 for ; Thu, 19 Aug 2010 17:57:16 -0700 (PDT) Received: from [192.168.0.221] (unknown [96.26.102.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 2C2162284A44; Thu, 19 Aug 2010 20:56:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Thu, 19 Aug 2010 20:57:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9AB503F4-203C-42DF-A948-9536768AFCD5@kumari.net> References: <8DD78B60-BA3E-4408-BDBA-AC65F981C84C@kirei.se> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1078) Cc: Tony Finch , keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 00:57:18 -0000 On Aug 19, 2010, at 7:43 PM, Richard L. Barnes wrote: > Why? Is it broken? >=20 > I've actually been thinking that CERT records will be one of the main = mechanisms we'll be using here. >=20 Me too -- I (still) believe that the CERT RR representation is the most = elegant -- there are a large number of type values that be be used to = represent whatever, and the "certificate or CRL" field is flexible = enough that we can extend it by having structured data in it if we need = to plomp in more than just a hash / key / blob. W >=20 >=20 >=20 > On Aug 19, 2010, at 7:26 PM, Tony Finch wrote: >=20 >> On Fri, 20 Aug 2010, Jakob Schlyter wrote: >>>=20 >>> We should keep in mind that RFC 4398 specifies a method to do this = for >>> PGP, e.g. look up CERT(jakob.kirei.se). >>=20 >> Aren't we aiming to supersede that? >>=20 >> Tony. >> --=20 >> f.anthony.n.finch http://dotat.at/ >> ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC = 7 TO >> SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH BECOMING = VERY >> ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR. >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9713A6359 for ; Thu, 19 Aug 2010 16:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vejDyxY5rmUz for ; Thu, 19 Aug 2010 16:57:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 4D6CC3A684B for ; Thu, 19 Aug 2010 16:57:24 -0700 (PDT) Received: from [128.89.253.232] (port=49572 helo=[192.168.5.86]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmEze-0007aW-HG; Thu, 19 Aug 2010 19:57:58 -0400 Message-Id: From: "Richard L. Barnes" To: Nicholas Weaver In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 19:57:57 -0400 References: <8DD78B60-BA3E-4408-BDBA-AC65F981C84C@kirei.se> <157B8B25-72DE-4A98-BDD9-4606E78D55C5@gmail.com> X-Mailer: Apple Mail (2.936) Cc: Tony Finch , "keyassure@ietf.org" , Phillip Hallam-Baker Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 23:57:26 -0000 Also, CERT records can carry certificates by reference, i.e., with a URI to a cert instead of the cert itself. So MTU / packet sizes shouldn't be an issue unless your URIs are crazy long. --Richar On Aug 19, 2010, at 7:56 PM, Nicholas Weaver wrote: > > On Aug 19, 2010, at 4:52 PM, Phillip Hallam-Baker wrote: > >> Main problem I have heard is that certs tend to be quite large in >> dns terms >> >> Some are larger than the Ethernet mtu. Most are bigger than the 512 >> bytes that idiot firewalls tend to filter. > > Actually, the idiot firewall isn't the problem for the most part, > but the Ethernet MTU is, but even then its still only a ~12% problem > or so. But you can always fall back to TCP for DNS with not too bad > a latency hit, especially if you design your DNS resolver to KNOW > there are dumb firewalls that can't handle fragments. > > However, keeping certs is arguably unnecessary: just a hash of a > cert accomplishes the same thing in pretty much any existing > cryptographic protocol, and for those that the DNS conveys the cert > itself rather than the presence of the cert, then yeah, you have the > size of the cert but you can manage: DNSSEC is already blowing out > the crap that can't handle fragments and/or 512B. > >> >> For ssl it is not necessary to have the cert as it is passed in >> band. Same for ssh (I think). corner case is smime but that is per >> user keying anyway. >> >> I was thinking of using a URL to retrieve the cert if that was >> necessary. Then you can get the trust path as well - if your app >> needs that. >> >> >> Sent from my iPad >> >> On Aug 19, 2010, at 7:43 PM, "Richard L. Barnes" >> wrote: >> >>> Why? Is it broken? >>> >>> I've actually been thinking that CERT records will be one of the >>> main mechanisms we'll be using here. >>> >>> >>> >>> >>> On Aug 19, 2010, at 7:26 PM, Tony Finch wrote: >>> >>>> On Fri, 20 Aug 2010, Jakob Schlyter wrote: >>>>> >>>>> We should keep in mind that RFC 4398 specifies a method to do >>>>> this for >>>>> PGP, e.g. look up CERT(jakob.kirei.se). >>>> >>>> Aren't we aiming to supersede that? >>>> >>>> Tony. >>>> -- >>>> f.anthony.n.finch http://dotat.at/ >>>> ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING >>>> CYCLONIC 7 TO >>>> SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH >>>> BECOMING VERY >>>> ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR. >>>> _______________________________________________ >>>> keyassure mailing list >>>> keyassure@ietf.org >>>> https://www.ietf.org/mailman/listinfo/keyassure >>> >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA39A3A6875 for ; Thu, 19 Aug 2010 16:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twL7vuzCCTEK for ; Thu, 19 Aug 2010 16:56:11 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 74C9F3A67F7 for ; Thu, 19 Aug 2010 16:56:11 -0700 (PDT) Received: by gwb20 with SMTP id 20so1147082gwb.31 for ; Thu, 19 Aug 2010 16:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=wy21c8xFOpKcKSQQyrnA1RoL9xUqGI1AG9n8TIq4Vu0=; b=b4px4VZlQl+5opJ84rK91j0k75z0UVN2jCvVECe0ttTO/Cp+7EF+mMLdNbctdAVzuW AZwtzHxsSm0dnD6D514xM2q69gRLsuYEAR35DTIv+onPfUDlukoM3CHaDo18Wc6AzdZ3 yRmNotdm8qChuDgTphtgS9tIiAtRBntpnRKsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=oT6LRZOMd+SMl6xMU1EuE6kJKtncgOKQvhvH2mgrgLKSeoPPOmBvpnlSYe3vfNyw7N HF7375sH0SK1ZL/GEcVEbvQXstOLIaXGoBremCNbFtMt2CDMkBW/vCdLUuPsCtdtFCcY sl9miaFDlBgCJirb4jqa2ubmHFsf6ZkcN3dBc= Received: by 10.150.68.4 with SMTP id q4mr834332yba.261.1282262205808; Thu, 19 Aug 2010 16:56:45 -0700 (PDT) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) by mx.google.com with ESMTPS id q36sm101507yba.0.2010.08.19.16.56.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 16:56:44 -0700 (PDT) Sender: Nicholas Weaver Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <157B8B25-72DE-4A98-BDD9-4606E78D55C5@gmail.com> Date: Thu, 19 Aug 2010 16:56:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DD78B60-BA3E-4408-BDBA-AC65F981C84C@kirei.se> <157B8B25-72DE-4A98-BDD9-4606E78D55C5@gmail.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: Tony Finch , "keyassure@ietf.org" Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 23:56:13 -0000 On Aug 19, 2010, at 4:52 PM, Phillip Hallam-Baker wrote: > Main problem I have heard is that certs tend to be quite large in dns = terms=20 >=20 > Some are larger than the Ethernet mtu. Most are bigger than the 512 = bytes that idiot firewalls tend to filter. Actually, the idiot firewall isn't the problem for the most part, but = the Ethernet MTU is, but even then its still only a ~12% problem or so. = But you can always fall back to TCP for DNS with not too bad a latency = hit, especially if you design your DNS resolver to KNOW there are dumb = firewalls that can't handle fragments. However, keeping certs is arguably unnecessary: just a hash of a cert = accomplishes the same thing in pretty much any existing cryptographic = protocol, and for those that the DNS conveys the cert itself rather than = the presence of the cert, then yeah, you have the size of the cert but = you can manage: DNSSEC is already blowing out the crap that can't handle = fragments and/or 512B. >=20 > For ssl it is not necessary to have the cert as it is passed in band. = Same for ssh (I think). corner case is smime but that is per user keying = anyway. >=20 > I was thinking of using a URL to retrieve the cert if that was = necessary. Then you can get the trust path as well - if your app needs = that.=20 >=20 >=20 > Sent from my iPad >=20 > On Aug 19, 2010, at 7:43 PM, "Richard L. Barnes" = wrote: >=20 >> Why? Is it broken? >>=20 >> I've actually been thinking that CERT records will be one of the main = mechanisms we'll be using here. >>=20 >>=20 >>=20 >>=20 >> On Aug 19, 2010, at 7:26 PM, Tony Finch wrote: >>=20 >>> On Fri, 20 Aug 2010, Jakob Schlyter wrote: >>>>=20 >>>> We should keep in mind that RFC 4398 specifies a method to do this = for >>>> PGP, e.g. look up CERT(jakob.kirei.se). >>>=20 >>> Aren't we aiming to supersede that? >>>=20 >>> Tony. >>> --=20 >>> f.anthony.n.finch http://dotat.at/ >>> ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC = 7 TO >>> SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH = BECOMING VERY >>> ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR. >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >>=20 >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A243A681E for ; Thu, 19 Aug 2010 16:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSqUa4cOnm8I for ; Thu, 19 Aug 2010 16:53:28 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 969B63A6853 for ; Thu, 19 Aug 2010 16:53:27 -0700 (PDT) Received: by qwc9 with SMTP id 9so2516980qwc.31 for ; Thu, 19 Aug 2010 16:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=xoKbzhq+xa2SA8yes9LO3aDMgW+HQFSTX3EkqAT2fL0=; b=XgwU/T09B+8Z1dk+N7SvmCxyFzv/orVcTMTES58AHvypBUsLvXJ/p5r1GVcqCW5Kp+ schoTIH+9U+ohZftK0401DX95w2mixQEhfb/MFf0Yp0/CTqBmywS0W7i7ICYkrwX1VPs G5XE5hfPiprQ1qCxUaCBpqfFuBzZJrKncyrqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=srYE/4bhIt6bDbptqETLFdbI0Tgb7J4MXOzfpCbgJJLHacd5G9QdlKcP5yxYqMu99/ 7PAfllGYvodAwE6ojC7t3am3Amf6mf6eyUNDM0h7SOdv3a/PsCGGEPACm2xlChnkB8+w V2mih+enxZx55rXaski0KXfODsvcssn6OcH8Q= Received: by 10.224.20.7 with SMTP id d7mr434440qab.90.1282262041911; Thu, 19 Aug 2010 16:54:01 -0700 (PDT) Received: from [10.0.1.8] (c-98-216-39-121.hsd1.ma.comcast.net [98.216.39.121]) by mx.google.com with ESMTPS id r1sm2390111qcq.46.2010.08.19.16.54.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 16:54:01 -0700 (PDT) References: Message-Id: <03F4A648-A4DC-42A6-9363-F52B5810715F@gmail.com> From: Phillip Hallam-Baker To: Tony Finch In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Thu, 19 Aug 2010 19:53:58 -0400 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] multi-application certificate RRs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 23:53:29 -0000 Yes zone walking is really really bad. Let's not do that. Sent from my iPad On Aug 19, 2010, at 7:47 PM, Tony Finch wrote: > On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote: >=20 >> There are issues with wildcards that are very specific to DKIM. >> Specifically, in DKIM you want to be able to create policy records >> that bind to *.example.com. >=20 > There are other email-related policy proposals (e.g. CSV "client SMTP > validation") that have the same problem. CSV specifies tree walking to > deal with wildcard problems, but tree walking is also discouraged. >=20 > http://www.bbiw.net/CSV/index.html >=20 > Tony. > --=20 > f.anthony.n.finch http://dotat.at/ > MALIN: EASTERLY 5 OR 6 BECOMING SOUTHWESTERLY GALE 8 TO STORM 10, = PERHAPS > VIOLENT STORM 11 LATER. ROUGH OR VERY ROUGH, BECOMING HIGH FOR A TIME. = RAIN OR > SQUALLY SHOWERS. MODERATE OR POOR. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9AD3A684B for ; Thu, 19 Aug 2010 16:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIvAb-mynih5 for ; Thu, 19 Aug 2010 16:52:07 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id F345F3A681E for ; Thu, 19 Aug 2010 16:52:06 -0700 (PDT) Received: by qyk9 with SMTP id 9so2457729qyk.10 for ; Thu, 19 Aug 2010 16:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=V5wLG4dYkUDr5VpygADuChkv6Bsn00Dzwyk4SeNLCrk=; b=ZB+DQyFjlz/YFfRCBQaNpzXgUmvkOntHjJ3LkZDLsrXhqjZeXarWC7BUCJyK2+lpaZ 9ePi2PkghSuoBf3ZOp00MK1NgoZn18R28hA5HDR5W5jp6tAZmPqenpOBpOXU3As9YW0/ Aj0tbUcTLHpi2hAGTxLk3vZwUJLWdkop4ZEjg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=hvnbfrhKHNt+A20N0nVUbqnqPnR0LzN0tb0Ila0dnNoOKfc/Kste6vUxQdj/nOpPE2 kqtSSmtAXmpS15lKk3uP4t2KDNn84HhHbVVJB9IiDG1wpv8gK0gsjtymYRWbdAd7njuw c3gRp4SLhre7lRF8AWk8eqkVk/gCWPTYb3Onk= Received: by 10.229.10.150 with SMTP id p22mr109589qcp.220.1282261961295; Thu, 19 Aug 2010 16:52:41 -0700 (PDT) Received: from [10.0.1.8] (c-98-216-39-121.hsd1.ma.comcast.net [98.216.39.121]) by mx.google.com with ESMTPS id r1sm2388426qcq.46.2010.08.19.16.52.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 16:52:40 -0700 (PDT) References: <8DD78B60-BA3E-4408-BDBA-AC65F981C84C@kirei.se> Message-Id: <157B8B25-72DE-4A98-BDD9-4606E78D55C5@gmail.com> From: Phillip Hallam-Baker To: "Richard L. Barnes" In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Thu, 19 Aug 2010 19:52:37 -0400 Cc: Tony Finch , "keyassure@ietf.org" Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 23:52:09 -0000 Main problem I have heard is that certs tend to be quite large in dns = terms=20 Some are larger than the Ethernet mtu. Most are bigger than the 512 = bytes that idiot firewalls tend to filter. For ssl it is not necessary to have the cert as it is passed in band. = Same for ssh (I think). corner case is smime but that is per user keying = anyway. I was thinking of using a URL to retrieve the cert if that was = necessary. Then you can get the trust path as well - if your app needs = that.=20 Sent from my iPad On Aug 19, 2010, at 7:43 PM, "Richard L. Barnes" = wrote: > Why? Is it broken? >=20 > I've actually been thinking that CERT records will be one of the main = mechanisms we'll be using here. >=20 >=20 >=20 >=20 > On Aug 19, 2010, at 7:26 PM, Tony Finch wrote: >=20 >> On Fri, 20 Aug 2010, Jakob Schlyter wrote: >>>=20 >>> We should keep in mind that RFC 4398 specifies a method to do this = for >>> PGP, e.g. look up CERT(jakob.kirei.se). >>=20 >> Aren't we aiming to supersede that? >>=20 >> Tony. >> --=20 >> f.anthony.n.finch http://dotat.at/ >> ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC = 7 TO >> SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH BECOMING = VERY >> ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR. >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A393A684B for ; Thu, 19 Aug 2010 16:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.586 X-Spam-Level: X-Spam-Status: No, score=-5.586 tagged_above=-999 required=5 tests=[AWL=1.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr7hIckYPd9J for ; Thu, 19 Aug 2010 16:46:58 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) by core3.amsl.com (Postfix) with ESMTP id EEBC23A6853 for ; Thu, 19 Aug 2010 16:46:57 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:55730) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1OmEpY-0007j0-15 (Exim 4.72) (return-path ); Fri, 20 Aug 2010 00:47:32 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OmEpY-000395-AH (Exim 4.67) (return-path ); Fri, 20 Aug 2010 00:47:32 +0100 Date: Fri, 20 Aug 2010 00:47:32 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: keyassure@ietf.org Subject: Re: [keyassure] multi-application certificate RRs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 23:47:31 -0000 On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote: > There are issues with wildcards that are very specific to DKIM. > Specifically, in DKIM you want to be able to create policy records > that bind to *.example.com. There are other email-related policy proposals (e.g. CSV "client SMTP validation") that have the same problem. CSV specifies tree walking to deal with wildcard problems, but tree walking is also discouraged. http://www.bbiw.net/CSV/index.html Tony. -- f.anthony.n.finch http://dotat.at/ MALIN: EASTERLY 5 OR 6 BECOMING SOUTHWESTERLY GALE 8 TO STORM 10, PERHAPS VIOLENT STORM 11 LATER. ROUGH OR VERY ROUGH, BECOMING HIGH FOR A TIME. RAIN OR SQUALLY SHOWERS. MODERATE OR POOR. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B9A3A67EF for ; Thu, 19 Aug 2010 16:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xE1tP68AOrXM for ; Thu, 19 Aug 2010 16:43:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 2F0493A6853 for ; Thu, 19 Aug 2010 16:43:26 -0700 (PDT) Received: from [128.89.253.232] (port=49503 helo=[192.168.5.86]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmEm8-0007Lh-T4; Thu, 19 Aug 2010 19:44:01 -0400 Message-Id: From: "Richard L. Barnes" To: Tony Finch In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 19:43:59 -0400 References: <8DD78B60-BA3E-4408-BDBA-AC65F981C84C@kirei.se> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 23:43:31 -0000 Why? Is it broken? I've actually been thinking that CERT records will be one of the main mechanisms we'll be using here. On Aug 19, 2010, at 7:26 PM, Tony Finch wrote: > On Fri, 20 Aug 2010, Jakob Schlyter wrote: >> >> We should keep in mind that RFC 4398 specifies a method to do this >> for >> PGP, e.g. look up CERT(jakob.kirei.se). > > Aren't we aiming to supersede that? > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC > 7 TO > SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH > BECOMING VERY > ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173A43A6875 for ; Thu, 19 Aug 2010 16:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.56 X-Spam-Level: X-Spam-Status: No, score=-5.56 tagged_above=-999 required=5 tests=[AWL=1.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyoDiwWEExEC for ; Thu, 19 Aug 2010 16:41:00 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) by core3.amsl.com (Postfix) with ESMTP id 528253A6A34 for ; Thu, 19 Aug 2010 16:40:37 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:49686) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1OmEjJ-0006r3-20 (Exim 4.72) (return-path ); Fri, 20 Aug 2010 00:41:05 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OmEjJ-0002Zn-JW (Exim 4.67) (return-path ); Fri, 20 Aug 2010 00:41:05 +0100 Date: Fri, 20 Aug 2010 00:41:05 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <50A38D0D-8F66-4A8B-836A-9C8A5C0F9280@bbn.com> <19F4493A-6E3E-418F-9643-1F8D578C3C20@gmail.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "keyassure@ietf.org" Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 23:41:02 -0000 On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote: > First off, remember that due to a bug in the way SSL was originally > designed, we currently have to burn an IPv4 address per SSL instance. > I know that there are work-arounds, but if you start to depend on them > you make th backwards compatibility story much harder. I don't do web seriously any more but I get the impression that the main brake on SNI deployment (like many other things) is IE6. > Say that I am managing 100,000 sites on 100 actual machines. Do I want > to have to manage 100,000 keys that are bound to the sites or 100 keys > that are bound to machines? Note that the sites float fairly freely > from machine to machine and moving crypto on machines that use crypto > accelerators is non-trivial. If the server farm acts as a single service then a single key would seem right to me. The crypto accelerator is more likely to live on the load balancer than the servers. Tony. -- f.anthony.n.finch http://dotat.at/ FAIR ISLE: CYCLONIC 5 BECOMING SOUTHERLY 7 TO SEVERE GALE 9, PERHAPS STORM 10 LATER. MODERATE OR ROUGH. RAIN. MODERATE OR POOR. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8413A6A48 for ; Thu, 19 Aug 2010 16:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0D7wt6bTknqs for ; Thu, 19 Aug 2010 16:40:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 34A273A6A21 for ; Thu, 19 Aug 2010 16:39:53 -0700 (PDT) Received: from [128.89.253.232] (port=49501 helo=[192.168.5.86]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmEig-0007If-Dg; Thu, 19 Aug 2010 19:40:26 -0400 Message-Id: From: "Richard L. Barnes" To: Warren Kumari In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 19:40:25 -0400 References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> <25610D95-3C55-4920-B33B-B420E8CF639B@gmail.com> X-Mailer: Apple Mail (2.936) Cc: Stephen Schultze , keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 23:40:59 -0000 +1 There's some analogy to be made here to the RPKI [1], which overlays a PKI attesting to Internet resource holdings on the existing hierarchy for managing these resources. Using the same management structure means the same set of people have to be trusted [2]. The security infrastructure just allows secured things to be tied back to these trusted entities. [1] [2] "trusted" in the sense of RFC 4949 :) On Aug 19, 2010, at 6:04 PM, Warren Kumari wrote: > > On Aug 19, 2010, at 12:40 PM, Stephen Schultze wrote: > >> David said basically what I was going to say on your other points, >> but I wanted to also note the following: >> >> On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote: >>> The point you are still not getting here is that the security of >>> the system is measured from the point of view of the relying >>> party. The relying party does not choose either the CA or the >>> Registrar, but an attacker can. >> >> >> Let's describe the assurances that the relying party has in each >> case: >> >> Standard CA DV cert: >> One of thousands of entities with cert-issuing authority said that >> the holder of the corresponding private key controls the zone for >> the domain in question. There may be other people out there who >> also have certificates that assert that they control the domain, >> but neither you nor this issuing CA necessarily know if they >> exist. Every root CA has equivalent authority as far as you're >> concerned, and an attacker can choose the lowest common denominator >> CA and serve you those certs at will. >> >> DNSSEC domain-key assertion: >> The person who controls the zone for the domain in question holds >> the corresponding private key. The only opportunity for mischief >> or mistake is in the one single path that the zone controller >> chose: their nameserver (especially if they are doing online >> signing), the registrar, the registry, and the root (and if there >> are DS records for sub-domains, whoever controls those). What's >> more, any substitution of a baddie's DS record for the true domain >> owner's DS record would be highly visible and likely to be >> immediately corrected. > > So, when I initially started looking at all this (leveraging the > DNSSEC TA as a TA for other things) I thought that it was the best > thing since sliced bread... until it occurred to me that this was > changing who all could muck with your security. > CA certs were handed out by CAs, and you didn't need to worry about > being attacked by your (probably outsourced) DNS provider, your > (probably reseller) registrar, their parent registrar and the > registry (or, more likely, the chappie who owned your nameserver > because you thought that 'P@ssword' was a good choice). I ended up > rewriting my initial draft saying that the only use for this was to > allow you to attest to what the *correct* CA issued cert was, and > apologized to the folk to whom I had given the original drafts to > for wasting their time... > A long set of emails and phonecalls and IMs then occurred, with me > kvetching about how this was changing the fundamental trust model, > and opening you up to dinking with by all of the folk in the > registration / DNS side of things and how the sky was falling... > but, for every scenario that I came up with (rogue DNS provider, > hacked nameserver, bad registrar) folk convinced me that the > attackers could just as easily redirect my MX record and use that to > obtain a CA signed cert... It took some time (I guess because I > didn't want to admit to myself just how screwed we were), but they > have fully convinced me -- once someone in a position to change your > DNS responses (by inserting DNSSEC signed keymaterial or something) > they are in a position to get a cert.... > > W > > > > >> >> DNSSEC domain-key assertion plus EV: >> Not only is there a high level of assurance that you are talking to >> the person who controls the zone, a third-party has verified who >> that person is. You can have a substantial degree of trust in that >> third-party because they have been approved according to the more >> stringent EV requirements. >> >> DNSSEC domain-key assertions are backed up by the technical >> architecture. CA assertions are backed up by standards groups, >> reputation, and perhaps even legal liability. >> >> The caveat for both systems are that technical vulnerabilities can >> and do happen, but I think that's well beyond this group's mandate >> to discuss. >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > -- > If the bad guys have copies of your MD5 passwords, then you have way > bigger problems than the bad guys having copies of your MD5 passwords. > -- Richard A Steenbergen > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D7053A6A24 for ; Thu, 19 Aug 2010 16:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.532 X-Spam-Level: X-Spam-Status: No, score=-5.532 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73di3HDiYNVC for ; Thu, 19 Aug 2010 16:30:41 -0700 (PDT) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) by core3.amsl.com (Postfix) with ESMTP id 36FDE3A67EF for ; Thu, 19 Aug 2010 16:30:41 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:47056) by ppsw-31.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1OmEZn-0001lR-K0 (Exim 4.72) (return-path ); Fri, 20 Aug 2010 00:31:15 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OmEZn-0001gY-62 (Exim 4.67) (return-path ); Fri, 20 Aug 2010 00:31:15 +0100 Date: Fri, 20 Aug 2010 00:31:15 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Nicholas Weaver In-Reply-To: <8A617A03-314E-4007-A792-0DF574CE7143@ICSI.Berkeley.EDU> Message-ID: References: <3C80DCF9-46B6-4714-83F5-1DE5243B93E2@icsi.berkeley.edu> <8A617A03-314E-4007-A792-0DF574CE7143@ICSI.Berkeley.EDU> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: keyassure@ietf.org Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 23:30:43 -0000 On Thu, 19 Aug 2010, Nicholas Weaver wrote: > On Aug 19, 2010, at 10:51 AM, Tony Finch wrote: > > > > Could you explain why you think [keys tied to IP addresses are] > > necessary? TLS doesn't currently bind names and addresses in this way, > > and doing so makes services less mobile than they could be. > > But SSH might: If you want to bind to system identity rather than > hostname, that would require asking based on IP. Not if hosts are mobile. With an infrastructure like Bonjour, hostnames have a more stable relationship to host identiry than IP addresses. Tony. -- f.anthony.n.finch http://dotat.at/ HEBRIDES: EASTERLY 4 BECOMING CYCLONIC GALE 8 TO STORM 10, PERHAPS VIOLENT STORM 11 LATER. ROUGH OR VERY ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR POOR. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A064E3A6A6D for ; Thu, 19 Aug 2010 16:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.502 X-Spam-Level: X-Spam-Status: No, score=-5.502 tagged_above=-999 required=5 tests=[AWL=1.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Klxs-MQPk6p for ; Thu, 19 Aug 2010 16:25:51 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) by core3.amsl.com (Postfix) with ESMTP id C538A3A6A0B for ; Thu, 19 Aug 2010 16:25:49 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:42014) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1OmEV6-0004E0-05 (Exim 4.72) (return-path ); Fri, 20 Aug 2010 00:26:24 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OmEV6-0001CF-0R (Exim 4.67) (return-path ); Fri, 20 Aug 2010 00:26:24 +0100 Date: Fri, 20 Aug 2010 00:26:24 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Jakob Schlyter In-Reply-To: <8DD78B60-BA3E-4408-BDBA-AC65F981C84C@kirei.se> Message-ID: References: <8DD78B60-BA3E-4408-BDBA-AC65F981C84C@kirei.se> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 23:25:52 -0000 On Fri, 20 Aug 2010, Jakob Schlyter wrote: > > We should keep in mind that RFC 4398 specifies a method to do this for > PGP, e.g. look up CERT(jakob.kirei.se). Aren't we aiming to supersede that? Tony. -- f.anthony.n.finch http://dotat.at/ ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH BECOMING VERY ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD8A13A67FA for ; Thu, 19 Aug 2010 15:03:38 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8DVCBw5JeEI for ; Thu, 19 Aug 2010 15:03:37 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 844183A6818 for ; Thu, 19 Aug 2010 15:03:37 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id 618F6DEE001; Thu, 19 Aug 2010 18:02:47 -0400 (EDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 7D15222849CC; Thu, 19 Aug 2010 18:02:46 -0400 (EDT) Message-Id: From: Warren Kumari To: Stephen Schultze In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 18:04:10 -0400 References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> <25610D95-3C55-4920-B33B-B420E8CF639B@gmail.com> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 22:03:39 -0000 On Aug 19, 2010, at 12:40 PM, Stephen Schultze wrote: > David said basically what I was going to say on your other points, > but I wanted to also note the following: > > On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote: >> The point you are still not getting here is that the security of >> the system is measured from the point of view of the relying party. >> The relying party does not choose either the CA or the Registrar, >> but an attacker can. > > > Let's describe the assurances that the relying party has in each case: > > Standard CA DV cert: > One of thousands of entities with cert-issuing authority said that > the holder of the corresponding private key controls the zone for > the domain in question. There may be other people out there who > also have certificates that assert that they control the domain, but > neither you nor this issuing CA necessarily know if they exist. > Every root CA has equivalent authority as far as you're concerned, > and an attacker can choose the lowest common denominator CA and > serve you those certs at will. > > DNSSEC domain-key assertion: > The person who controls the zone for the domain in question holds > the corresponding private key. The only opportunity for mischief or > mistake is in the one single path that the zone controller chose: > their nameserver (especially if they are doing online signing), the > registrar, the registry, and the root (and if there are DS records > for sub-domains, whoever controls those). What's more, any > substitution of a baddie's DS record for the true domain owner's DS > record would be highly visible and likely to be immediately corrected. So, when I initially started looking at all this (leveraging the DNSSEC TA as a TA for other things) I thought that it was the best thing since sliced bread... until it occurred to me that this was changing who all could muck with your security. CA certs were handed out by CAs, and you didn't need to worry about being attacked by your (probably outsourced) DNS provider, your (probably reseller) registrar, their parent registrar and the registry (or, more likely, the chappie who owned your nameserver because you thought that 'P@ssword' was a good choice). I ended up rewriting my initial draft saying that the only use for this was to allow you to attest to what the *correct* CA issued cert was, and apologized to the folk to whom I had given the original drafts to for wasting their time... A long set of emails and phonecalls and IMs then occurred, with me kvetching about how this was changing the fundamental trust model, and opening you up to dinking with by all of the folk in the registration / DNS side of things and how the sky was falling... but, for every scenario that I came up with (rogue DNS provider, hacked nameserver, bad registrar) folk convinced me that the attackers could just as easily redirect my MX record and use that to obtain a CA signed cert... It took some time (I guess because I didn't want to admit to myself just how screwed we were), but they have fully convinced me -- once someone in a position to change your DNS responses (by inserting DNSSEC signed keymaterial or something) they are in a position to get a cert.... W > > DNSSEC domain-key assertion plus EV: > Not only is there a high level of assurance that you are talking to > the person who controls the zone, a third-party has verified who > that person is. You can have a substantial degree of trust in that > third-party because they have been approved according to the more > stringent EV requirements. > > DNSSEC domain-key assertions are backed up by the technical > architecture. CA assertions are backed up by standards groups, > reputation, and perhaps even legal liability. > > The caveat for both systems are that technical vulnerabilities can > and do happen, but I think that's well beyond this group's mandate > to discuss. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure -- If the bad guys have copies of your MD5 passwords, then you have way bigger problems than the bad guys having copies of your MD5 passwords. -- Richard A Steenbergen Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EAF63A67FA for ; Thu, 19 Aug 2010 15:01:56 -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_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDoONQ1gwKUr for ; Thu, 19 Aug 2010 15:01:55 -0700 (PDT) Received: from mail.kirei.se (wagaya.kirei.se [91.206.174.10]) by core3.amsl.com (Postfix) with ESMTP id D986B3A68E7 for ; Thu, 19 Aug 2010 15:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kirei.se; s=wagaya20060620; t=1282255347; bh=2QEUvULkwFMPBgqwrnx+46vZWEUydzCk7w1OAt3g4IU=; h=Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sJJfsaBfHBHXBTbv/l9HqvQxwG7fRnrAcqdvA9+Ghd78v3oWetZfz0eO5X/LC4lOd fq5kD8ukll4hxubK1lgrEH+FvxeZy/dWsTdnQtkX/qOFbnrHyWmL9AvVfTLof5Z2Fw ADMRv/u11ar4jN7zxtppBuV/Ws1tETcIxC7mQjV8= Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Fri, 20 Aug 2010 00:02:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8DD78B60-BA3E-4408-BDBA-AC65F981C84C@kirei.se> References: To: Tony Finch X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 22:01:56 -0000 On 19 aug 2010, at 19.08, Tony Finch wrote: > Yes. At the moment the PKIs for identifying people are rather = cumbersome. > It would be nice to be able to use DNSSEC for verifying S/MIME or PGP > messages. We should keep in mind that RFC 4398 specifies a method to do this for = PGP, e.g. look up CERT(jakob.kirei.se). jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E2A3A68A0 for ; Thu, 19 Aug 2010 14:43:00 -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_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVs5vNW4iZMj for ; Thu, 19 Aug 2010 14:42:59 -0700 (PDT) Received: from mail.kirei.se (wagaya.kirei.se [91.206.174.10]) by core3.amsl.com (Postfix) with ESMTP id 992973A680B for ; Thu, 19 Aug 2010 14:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kirei.se; s=wagaya20060620; t=1282254208; bh=PyMoJP82DnQQ9waW5QRq3bwgPsPxN+oFGbC/o5yQTSQ=; h=Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=x3N+dXVe2px2gR4cQqGXSIKjoBX3TmfRO1A3XJkgciyTcuFPiZrr10w7PjK/65AU4 QEBJFiEOPrOj5JG9kxYLC92s2Qz+UP1VsasVxTevKa2J2PyfguQvHPvhp3Th9KQWzf 1lSTIuxBSkeREinweKqMujekfRSs2irLwaeKDFn4= Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Thu, 19 Aug 2010 23:43:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1081) Cc: Tony Finch , keyassure@ietf.org, Phillip Hallam-Baker Subject: Re: [keyassure] multi-application certificate RRs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 21:43:01 -0000 On 19 aug 2010, at 19.18, Richard L. Barnes wrote: > _xmpp-client._tcp.example.com CERT 1 1 1 http://example.com/xmpp.cer why serve the cert over HTTP, when you can provide a fingerprint of the = public key that you should expect via DNS (with DNSSEC) right away? > If you're assuming DNSSEC and want to bind a key to a name, you don't = need to attach the CRYPTO/CERT/whatever RR to the SRV. Since the SRV is = DNSSEC-signed, the target host just needs to authenticate as itself, so = you would want the key to go with the target hostname (or its A/AAAA = record). +1 jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B8D3A6987 for ; Thu, 19 Aug 2010 13:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[AWL=1.511, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juyFYw0VB8k4 for ; Thu, 19 Aug 2010 13:58:07 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 0322E3A6895 for ; Thu, 19 Aug 2010 13:58:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=AfaZPlXAQExRc4TzxZI3CUtNjtx5WXB53dW50Ri+vRac+tWAyGKuhW0GKfyVbjYP; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OmCC8-0003un-MQ; Thu, 19 Aug 2010 16:58:40 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Thu, 19 Aug 2010 16:58:40 -0400 Message-ID: <329621.1282251520679.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Thu, 19 Aug 2010 15:58:40 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: David Conrad , Phillip Hallam-Baker Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688b776f8ef5a8fb0c5e3128f89b7e6b49b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 20:58:08 -0000 David and all, The choices for whom to trust are: Verisign, ICANN, or the USG. Well that's a poor group to pick from according to many folks, eh Dave? >;) As most americans know the trust in their government is at a nearly 70 year low, Trust in ICANN has ebbed and flowed but is nearly as low, and Verisign all be they have good folks there, seems to be the default remaining choice. Seems like a logical deduction choice that leaves in some folks mind and experiance, not very good choices. We need more choices OR we need better choices, take your pick. The 'Truste Anchors' approach in DNSSEC gives a few more, but perhaps not enough OR not the 'Right' ones to choose from? -----Original Message----- >From: David Conrad >Sent: Aug 18, 2010 10:42 PM >To: Phillip Hallam-Baker >Cc: keyassure@ietf.org >Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications > >On Aug 18, 2010, at 7:26 PM, Phillip Hallam-Baker wrote: >> I want to use dnssec without the ICANN root. > >Feel free. There are (currently) only about 300 TLD trust anchors you'll have to keep track of if all the TLDs started signing. ICANN says they'll be adding no more than about 1000/year. You'll have to figure out a way of securely fetching the trust anchors from the TLD admins who sign their zones to install into your validating resolver, but that's a minor detail. > >A single root of trust _can be_ better since there are less parties to vet and audit (1 versus many). However, as I said, if you don't want to trust ICANN, VeriSign, and the US Government, you don't have to. > >Regards, >-drc > >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B24C3A67AC for ; Thu, 19 Aug 2010 13:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbTmR9tlbGGG for ; Thu, 19 Aug 2010 13:18:13 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 290CB3A6407 for ; Thu, 19 Aug 2010 13:18:12 -0700 (PDT) Received: by gxk20 with SMTP id 20so1071661gxk.31 for ; Thu, 19 Aug 2010 13:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MY3n6qyyG7DnaDQPXKd4f03AoPoNhzJ5DMQlABUeqZY=; b=sSrlprAbR5AsXYW/eh30bwUzZrfmGEWi7bqb2fkacm0k7qgTvj1Q8O3TiZ5gMPaVrn neVGNE9V12qAXRVnSVSl5yrk7fs/Ayi6IbJL+CJPfcuvqn+jU08DmKl4AqkGLAu9oX3U EAYTSm5OE8mYKvSsZvN+6IhccjU/pgfTEKTKg= 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:content-transfer-encoding; b=iGJ4Xe0pCMdMRFo5+xfksYxnE7H5VnnmGSOJoF2maMGdl+9PLJK7Xd0tennRnLuDK7 gkKx6gH+DbcnEzvxipKW36wBcd58twV4jZxEP0bt7kg50BDHWf8yva2Bp7pOC28exhmN 0B3zUbH/NSAFTxCZ+EBj2fYxSveJDvhyi3DKU= MIME-Version: 1.0 Received: by 10.150.206.16 with SMTP id d16mr581667ybg.338.1282249127275; Thu, 19 Aug 2010 13:18:47 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 19 Aug 2010 13:18:46 -0700 (PDT) In-Reply-To: References: <185111DC-53F3-4DB0-A00B-185F30EF3493@bbn.com> <995AC4D8-5370-4E18-96B0-703DDB7D1A80@bbn.com> Date: Thu, 19 Aug 2010 16:18:46 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Tony Finch , keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 20:18:14 -0000 I think it is very clear that we are all agreed that we want this functiona= lity. But there is a distinct difference of opinion as to whether this should be done using the DNS alone or by using the DNS to provide a secured like to a service where the data is managed. We already have protocols for the second approach. What we do not have is a mechanism for finding out that the data is on offer. Extending my previous proposal _smtp._tcp.example.com OPTIONS "ssl=3Doffered SMIME=3DXKMS,PKIXREP" (see RFC 4386 for more info) On Thu, Aug 19, 2010 at 4:02 PM, Richard L. Barnes wrote: > I'm willing to admit that there are ways to massage different identifiers > into the DNS if you want to. =A0It just seems to me like that work is mor= e the > domain of the working groups that are focused on the applications that us= e > those identifiers, rather than a group focused on DNS and security. =A0If= the > application can map an identifier to a domain name, we can handle it, but= I > don't think we should be focused on defining mappings for all the differe= nt > identifiers that are around. > > Let me try to clarify what I meant when I said "the DNS is about domain > names". =A0As an example, consider the difference between domain names an= d SIP > URIs and how they're managed. Information about a domain name is stored i= n a > name server, in the form of RRs. =A0Information about a SIP URI is stored= in a > SIP registrar. =A0When a DNS application wants information about a domain > name, it asks the name server; when a SIP application wants information > about a URI, it asks the registrar. > > If information about a SIP URI is going to be published in the DNS, then = it > has to be transferred from the registrar to a name server. =A0In addition= to > the brittleness this introduces (in terms of keeping data in sync, making > sure the name translation is done properly, etc.), there's also something= of > a security concern here. =A0Now a relying party has to trust two entities > instead of one for the information it's using at the application layer -- > the registrar and the name server. =A0Even if the registrar is completely > honest, the operator of the name server might be able to bid down securit= y > by saying that there's no public key available for the URI in question. > > The up-shot is that it seems like the client/RP should be able to ask the > registrar directly. =A0In SIP, you might use a presence request; in SMTP,= you > might add a header that UAs can cache. =A0There doesn't seem to me to be = any > especial benefit in doing it in the DNS, especially since the needs of > different applications can be very different. > > --Richard > > > > On Aug 19, 2010, at 3:19 PM, David Conrad wrote: > >> On Aug 19, 2010, at 11:07 AM, Richard L. Barnes wrote: >>>> >>>> In many cases user keys have a username@domain structure so it would >>>> make >>>> sense for user keys to be signed by a domain key which can in turn be >>>> validated using the DNS. >>> >>> Although many user identifiers have that form superficially, there are >>> more worms here than you expect. =A0If you're going to be precise and >>> thorough, you'll need to address the full syntax of the URI scheme you'= re >>> considering, which is significantly more complex. >> >> Why would you need to deal with the full syntax of a URI? =A0What scenar= ios >> are you imagining that would suggest we can't solve the username@domain >> structure? =A0My understanding of the suggestion (which may be wrong) is >> signing something like >> >> $ORIGIN virtualized.org. >> drc =A0 =A0 IN PGPKEY >> drc =A0 =A0 IN SMIMEKEY >> ... >> >>> And this is not mentioning things like internationalization... >> >> Which isn't a problem since the DNS is 8-bit clean and since you don't >> have to worry about backwards compatibility, you could put anything into= the >> label. =A0The only constraint is the label has to be less than 64 bytes. >> >>> Even if you went to the trouble of defining a mapping, it would just be >>> an specific way of constructing the names you would use to find keys fo= r a >>> given type of identifier. =A0Nothing would be different about how the >>> information is encoded in the DNS. >> >> Right. =A0It would just be using the DNS as a distributed tag lookup sys= tem >> that now returns validatable values. =A0Which is OK since that is what t= he DNS >> is. >> >>> Like Paul said, the DNS is about domain names. >> >> I honestly don't understand what this means. >> >>> A zone is authoritative for the names it contains. =A0If you start talk= ing >>> about things like email addresses, you have a whole different way that >>> identifiers are assigned, and the trust model should map along with tha= t. >> >> A whole different way than what? =A0I'd think that if you care about the >> trust model mapping to the way the identifiers were assigned, you'd do z= one >> delegations to make that happen. >> >> I'm clearly missing something. >> >> Regards, >> -drc >> > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291F23A693E for ; Thu, 19 Aug 2010 13:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQSV2tsprMWJ for ; Thu, 19 Aug 2010 13:11:24 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DF6B03A6A5A for ; Thu, 19 Aug 2010 13:11:06 -0700 (PDT) Received: by mail-iw0-f172.google.com with SMTP id 3so2342996iwn.31 for ; Thu, 19 Aug 2010 13:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P84/ixyllTgar+VwZTbmomz3LByp2vrSU+cDfPhfgf8=; b=dugzG6mwUL89Q2COJm6XBgpYnjoUOyrSUn5F9YS3YT+P8cioVSrCHdMfXjz4Qr4TZI NJehpxeh3WL/Dnqv2dwZraHOuRPpzPi0S9do1b7dogtEEWKJajo1Qlfmjd0tcowixkK8 flB6AxIlsP1PPb5vK30ofcajy4mPCIwAwTelc= 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:content-transfer-encoding; b=DQI8ReEVQy/899i/ZsF+dprROyypWrvtVXVn9TmqhtoyZ1R1pGDTOR4P49pPO0oo+G Yt9zdHeqTECOPglkRb1fYXkUNyu7oJPnLx9srwPWB0sg/qjUUn7CtcWH0mBZvHWy+GfV 0AyhoVjR4Kr2J6tsv6F1BRM5CjzOwGde8LAaU= MIME-Version: 1.0 Received: by 10.231.172.75 with SMTP id k11mr469499ibz.4.1282248701302; Thu, 19 Aug 2010 13:11:41 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 19 Aug 2010 13:11:41 -0700 (PDT) In-Reply-To: References: <50A38D0D-8F66-4A8B-836A-9C8A5C0F9280@bbn.com> <19F4493A-6E3E-418F-9643-1F8D578C3C20@gmail.com> Date: Thu, 19 Aug 2010 16:11:41 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "keyassure@ietf.org" Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 20:11:28 -0000 First off, remember that due to a bug in the way SSL was originally designed, we currently have to burn an IPv4 address per SSL instance. I know that there are work-arounds, but if you start to depend on them you make th backwards compatibility story much harder. What we are trying to do here is to make use of crypto as easy and painless as possible. So we should make as much effort as possible to conform to the existing infrastructure rather than create unnecessary restrictions. Take for example the common case today where we have 300 web servers on one host with one IP address. At the moment only one of those virtual web servers can have SSL enabled since the client does not tell the server which domain it is interested in until after the cert is transferred. Say that I am managing 100,000 sites on 100 actual machines. Do I want to have to manage 100,000 keys that are bound to the sites or 100 keys that are bound to machines? Note that the sites float fairly freely from machine to machine and moving crypto on machines that use crypto accelerators is non-trivial. If the crypto keys are bound to the machine, then all I need to do to transfer a virtual web server is to move the content and once that is complete flip the relevant bits in the DNS to redirect queries. When I started I was looking at three RRs to support the features I consider necessary. But I now see that I could do it with a single record, provided that it is extensible. Say that a web client is trying to connect to www.example.com. Today the resolution process begins with pulling the A record. I suggest that instead the client should make requests for: www.example.com A _http._tcp.example.com OPTIONS These can fire in parallel so there is no real performance hit. The OPTIONS record is a list of ASCII encoded tag-value pairs, just like TXT and just like DKIM uses. The record may contain: * key information * security policy information * protocol information All the fields in the record are defined on a per-application protocol record basis. So there would be a general draft and an application specific draft to state how to use this record with HTTP, SMTP, SUBMIT, IMAP, POP3 and others. For the simplest Web site the record might be _http._tcp.www.example.com OPTIONS "ssl=3Doffered certh=3D(sha2,0b92c7808b91f7dc1cadaf8f9afe4d9834372adcc3e18f1d 4df6704768eea870)" For a site with two separate inbound SMTP servers we would want to have separate keys because the failover is being run by another company that we don't want to give a key to: _smtp._tcp.example.com OPTIONS "ssl=3Doffered" cert1._smtp._tcp.example.com OPTIONS "ssl=3Doffered certh=3D(3e8e64500a2ac1ea38203ef943c5e3188e1e537076b7846219996aa225e76c0e)" cert2._smtp._tcp.example.com OPTIONS "ssl=3Doffered certh=3D(a7fc2dcd765f94801bc06edd6420aad6cfe7fbfaa38113a5 e860a00607343b0d)" Each cert has an X.509v3 extension inside to disambiguate it from other certs for that service. For the IMAP service, SSL is required rather than merely supported. So we h= ave: _submit._tcp.example.com OPTIONS "ssl=3Drequired SRV" _imap._tcp.example.com OPTIONS "ssl=3Drequired SRV" _pop._tcp.example.com OPTIONS "ssl=3Drequired SRV" A mail client that understood this record could complete the entire account configuration correctly from the email address, authentication info and this record alone. And since the binding is to an SRV record rather than to specific host names as is current practice, maintenance of large sites is made easier. I am not certain how SSH fits into this scheme. I typically use SSH to log into specific machines. But since SSH can use certificates, people could put the disambiguating blob in the cert should they need it. This approach also opens up possibilities of specifying other protocol enhancements. I slipped in SRV earlier, there could well be other options. On Thu, Aug 19, 2010 at 1:55 PM, Tony Finch wrote: > On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote: >> On Aug 19, 2010, at 1:39 PM, Tony Finch wrote: >> > >> > Who buys multiple certificates when they only need one? >> >> People who read their terms of service? > > :-) > > IME, though one might need to buy a licence to use a certificate on > multiple hosts, this does not mean one needs multiple certificates > associated with multiple private keys. > > Tony. > -- > f.anthony.n.finch =A0 =A0http://dotat.at/ > IRISH SEA: SOUTHEAST, VEERING SOUTH 5 TO 7, OCCASIONALLY GALE 8. MODERATE= OR > ROUGH. RAIN THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8623A6A44 for ; Thu, 19 Aug 2010 13:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YznFjKEiHzh6 for ; Thu, 19 Aug 2010 13:10:44 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4BDA43A6A1F for ; Thu, 19 Aug 2010 13:10:44 -0700 (PDT) Received: by iwn3 with SMTP id 3so2342996iwn.31 for ; Thu, 19 Aug 2010 13:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u/0rjjFDMinMewsTgoM5ZLuXoas5haIsb7o6laxn/P0=; b=ffGROJBX4btyXwNznXzvrgagcQUMd4gyUPe/pnetoZc7pQwx8okeKeZTk/AUfZvk5Y Oy5w3jLA4+Gx7GHKKWiulhHwmsz5bnwARX/M3yiASxp3owN5EnzeOAQtDco1AMZUvk9d FA+9usIHmWK3IhBCNCsa7wPc7XfujeFdp43gg= 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:content-transfer-encoding; b=dJaJf7YGf9aVehE0Y7FLIhe4AwtK2Q2b2vYYPMBnqb2i5Kwu6n+kQydBdf+AMjWS+/ yEwloMUp3L67WoVSNlnzM28V14Vh8D9A3mm1vYqLsF+X+m/xERrRUe7n4rIExoVwRT5b tW9sYl/RzlQHWa1CP63b0Isa6Dulgz8eNMWZs= MIME-Version: 1.0 Received: by 10.231.182.9 with SMTP id ca9mr298247ibb.120.1282248636483; Thu, 19 Aug 2010 13:10:36 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 19 Aug 2010 13:10:36 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Aug 2010 16:10:36 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] multi-application certificate RRs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 20:11:07 -0000 There are issues with wildcards that are very specific to DKIM. Specifically, in DKIM you want to be able to create policy records that bind to *.example.com. I don't see that as a problem here. But it is not insoluble in any case. It would be addressed by XPTR. The bigger problem is with using prefixes as a substitute for requesting a new record by overloading TXT. There you have the problem that a wildcard for one purpose can clobber unrelated prefixes. That is not a problem here because we are using a separate record. On Thu, Aug 19, 2010 at 2:02 PM, Tony Finch wrote: > On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote: > >> I would hope that if we get people to start using DNS for their keying >> material that there would also be more widespread use of SRV. >> Wouldn't it make sense to use the exact same approach for the protocol >> specific keying information? > > RFC 5507 argues against SRV-style name prefixes because they interact > badly with wildcards. On the other hand it is rather complacent about RR > type exhaustion. > > Tony. > -- > f.anthony.n.finch =A0 =A0http://dotat.at/ > SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD= . > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4934F3A6881 for ; Thu, 19 Aug 2010 13:02:40 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Sz4iOZBDXFS for ; Thu, 19 Aug 2010 13:02:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id F2D803A68D4 for ; Thu, 19 Aug 2010 13:02:38 -0700 (PDT) Received: from [192.1.255.185] (port=53667 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmBKT-000HaR-6Z; Thu, 19 Aug 2010 16:03:13 -0400 Message-Id: From: "Richard L. Barnes" To: David Conrad In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 16:02:58 -0400 References: <185111DC-53F3-4DB0-A00B-185F30EF3493@bbn.com> <995AC4D8-5370-4E18-96B0-703DDB7D1A80@bbn.com> X-Mailer: Apple Mail (2.936) Cc: Tony Finch , keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 20:02:40 -0000 I'm willing to admit that there are ways to massage different identifiers into the DNS if you want to. It just seems to me like that work is more the domain of the working groups that are focused on the applications that use those identifiers, rather than a group focused on DNS and security. If the application can map an identifier to a domain name, we can handle it, but I don't think we should be focused on defining mappings for all the different identifiers that are around. Let me try to clarify what I meant when I said "the DNS is about domain names". As an example, consider the difference between domain names and SIP URIs and how they're managed. Information about a domain name is stored in a name server, in the form of RRs. Information about a SIP URI is stored in a SIP registrar. When a DNS application wants information about a domain name, it asks the name server; when a SIP application wants information about a URI, it asks the registrar. If information about a SIP URI is going to be published in the DNS, then it has to be transferred from the registrar to a name server. In addition to the brittleness this introduces (in terms of keeping data in sync, making sure the name translation is done properly, etc.), there's also something of a security concern here. Now a relying party has to trust two entities instead of one for the information it's using at the application layer -- the registrar and the name server. Even if the registrar is completely honest, the operator of the name server might be able to bid down security by saying that there's no public key available for the URI in question. The up-shot is that it seems like the client/RP should be able to ask the registrar directly. In SIP, you might use a presence request; in SMTP, you might add a header that UAs can cache. There doesn't seem to me to be any especial benefit in doing it in the DNS, especially since the needs of different applications can be very different. --Richard On Aug 19, 2010, at 3:19 PM, David Conrad wrote: > On Aug 19, 2010, at 11:07 AM, Richard L. Barnes wrote: >>> In many cases user keys have a username@domain structure so it >>> would make >>> sense for user keys to be signed by a domain key which can in turn >>> be >>> validated using the DNS. >> >> Although many user identifiers have that form superficially, there >> are more worms here than you expect. If you're going to be precise >> and thorough, you'll need to address the full syntax of the URI >> scheme you're considering, which is significantly more complex. > > Why would you need to deal with the full syntax of a URI? What > scenarios are you imagining that would suggest we can't solve the > username@domain structure? My understanding of the suggestion > (which may be wrong) is signing something like > > $ORIGIN virtualized.org. > drc IN PGPKEY > drc IN SMIMEKEY > ... > >> And this is not mentioning things like internationalization... > > Which isn't a problem since the DNS is 8-bit clean and since you > don't have to worry about backwards compatibility, you could put > anything into the label. The only constraint is the label has to be > less than 64 bytes. > >> Even if you went to the trouble of defining a mapping, it would >> just be an specific way of constructing the names you would use to >> find keys for a given type of identifier. Nothing would be >> different about how the information is encoded in the DNS. > > Right. It would just be using the DNS as a distributed tag lookup > system that now returns validatable values. Which is OK since that > is what the DNS is. > >> Like Paul said, the DNS is about domain names. > > I honestly don't understand what this means. > >> A zone is authoritative for the names it contains. If you start >> talking about things like email addresses, you have a whole >> different way that identifiers are assigned, and the trust model >> should map along with that. > > A whole different way than what? I'd think that if you care about > the trust model mapping to the way the identifiers were assigned, > you'd do zone delegations to make that happen. > > I'm clearly missing something. > > Regards, > -drc > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4283A659C for ; Thu, 19 Aug 2010 12:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7maeWwZ0l2B for ; Thu, 19 Aug 2010 12:46:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 7A72F3A6956 for ; Thu, 19 Aug 2010 12:46:45 -0700 (PDT) Received: from [192.1.255.185] (port=53577 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmB56-0002NL-4d; Thu, 19 Aug 2010 15:47:20 -0400 Message-Id: <9D7CE149-9275-4319-A2C8-890598286DDD@bbn.com> From: "Richard L. Barnes" To: Nicholas Weaver In-Reply-To: <8A617A03-314E-4007-A792-0DF574CE7143@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 15:47:18 -0400 References: <3C80DCF9-46B6-4714-83F5-1DE5243B93E2@icsi.berkeley.edu> <8A617A03-314E-4007-A792-0DF574CE7143@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.936) Cc: Tony Finch , keyassure@ietf.org Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:46:46 -0000 Depends on what you mean by "system identity", doesn't it? I tend to take a user-centric view of this. If I type in "ssh 10.1.1.1", then the key should be bound to the address, but if I type in "ssh example.com", the key should be bound to the name -- I don't care what the IP address is as long as the guy at the other end has the right key for the domain. This does raise an interesting question for the group, though: How do we want to handle "https://10.1.1.1/" and "https://[fe80::abcd: 123]/"? Seems like there are two basic possibilities: 1. Use the reverse DNS tree 2. Declare it out of scope because we're focused authenticating domain names My slight preference is for (2). --Richard On Aug 19, 2010, at 3:43 PM, Nicholas Weaver wrote: > > On Aug 19, 2010, at 10:51 AM, Tony Finch wrote: > >> On Thu, 19 Aug 2010, Nicholas Weaver wrote: >>> >>> However, service should be identified by both hostname AND IP >>> address >>> depending on the server's preference, thus any scheme that says >>> >>> _keymaterial_.host.mydomain.com as a query should also include a >>> query for >>> >>> _keymaterial_.{A/AAAA record for host.mydomain.com}, IFF the >>> reference >>> for _keymaterial_.host.mydomain.com says that IP should be >>> referred OR >>> the service was contacted based on IP rather than hostname. >> >> Could you explain why you think this is necessary? TLS doesn't >> currently >> bind names and addresses in this way, and doing so makes services >> less >> mobile than they could be. > > But SSH might: If you want to bind to system identity rather than > hostname, that would require asking based on IP. > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EDA23A680D for ; Thu, 19 Aug 2010 12:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z6XUwV6DETI for ; Thu, 19 Aug 2010 12:43:14 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 58CDD3A659C for ; Thu, 19 Aug 2010 12:43:14 -0700 (PDT) Received: by pvg7 with SMTP id 7so1016245pvg.31 for ; Thu, 19 Aug 2010 12:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Bm5PaYjesOWmQt6A0r8kHUHo9a9fXcXZO9ivS/GJn8U=; b=ikauk0BMSZ5/A7IQL4Uk/qNZMHD1y0NPAcugbtDUIWPP5uMH2UytZbG6m+S3xTux6K XVc1paYTOI2YrgEcv7isS/5UTQLVVKfAQ13GCDzoXcdE6d05cXMkx7gUo1QKxymIih7v L0kKJ4Gsy8auD+nTfcRgaxS8lKPTWRCXxRwvg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=GkT7WIKIyuGyCXY94J5cZbA/e79J7AufGEGA/7h2ow+iVf3+PwsuWGo3VQ9GShMuDw XToTXv3AocKdbJFwZu5IEbBF7EAm+8Nkc8xIJI3ApNqO2SE4RJcir+uWurHJK0hJQ1c9 jiwwrnGxSjxAHhY1QQfdSoCjKpFdo00+7Gsus= Received: by 10.142.207.9 with SMTP id e9mr273174wfg.143.1282247029248; Thu, 19 Aug 2010 12:43:49 -0700 (PDT) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) by mx.google.com with ESMTPS id v13sm2142233wfv.5.2010.08.19.12.43.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 12:43:48 -0700 (PDT) Sender: Nicholas Weaver Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Thu, 19 Aug 2010 12:43:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8A617A03-314E-4007-A792-0DF574CE7143@ICSI.Berkeley.EDU> References: <3C80DCF9-46B6-4714-83F5-1DE5243B93E2@icsi.berkeley.edu> To: Tony Finch X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, Nicholas Weaver Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:43:15 -0000 On Aug 19, 2010, at 10:51 AM, Tony Finch wrote: > On Thu, 19 Aug 2010, Nicholas Weaver wrote: >>=20 >> However, service should be identified by both hostname AND IP address >> depending on the server's preference, thus any scheme that says >>=20 >> _keymaterial_.host.mydomain.com as a query should also include a = query for >>=20 >> _keymaterial_.{A/AAAA record for host.mydomain.com}, IFF the = reference >> for _keymaterial_.host.mydomain.com says that IP should be referred = OR >> the service was contacted based on IP rather than hostname. >=20 > Could you explain why you think this is necessary? TLS doesn't = currently > bind names and addresses in this way, and doing so makes services less > mobile than they could be. But SSH might: If you want to bind to system identity rather than = hostname, that would require asking based on IP. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CF83A6A3C for ; Thu, 19 Aug 2010 12:38:06 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5LlBXCFJ4iK for ; Thu, 19 Aug 2010 12:38:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id CCE003A6A4F for ; Thu, 19 Aug 2010 12:37:55 -0700 (PDT) Received: from [192.1.255.185] (port=53533 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmAwB-0002AM-U9; Thu, 19 Aug 2010 15:38:08 -0400 Message-Id: From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 15:38:07 -0400 References: <87B7EB98-3F68-4C0C-9420-5B7D4BDF75D6@bbn.com> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Alternative Charter Proposal X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:38:07 -0000 I don't think this text claims that one model is better than another (ok, except for the word "problem"), just that they offer different characteristics. Namely, in DNSSEC, the key heirarchy overlays is the DNS heirarchy, while with the traditional CA model, the key heirarchy isn't related to anything in particular. If you want, we could eliminate the second and third paragraphs that discuss the different models, but it seems like the charter should explain why what we're doing is different from what has happened in the past. Neither this charter nor any other document can say anything about the "validity" of a trust model. As always, it's up to the entity that's authenticating to choose what system he wants to use to claim an identity, and it's up to an RP to decide what he trusts. The only question about trust models that is germane to the charter discussion is whether there exist domain operators who want to assert name/key bindings in the DNS for use with security protocols, and whether there are relying parties who would be interested in using this information. If the answer is "yes", then the work should proceed, IMO, with about the scope described below. And the sense I got in the room in Maastricht was that the answer is "yes". --Richard On Aug 19, 2010, at 3:18 PM, Phillip Hallam-Baker wrote: > That is still an architectural statement, not a problem statement. > > If you want to put statements into the charter asserting the benefit > of one particular trust topology, then you have to accept the argument > over whether those claims are actually true as being in scope for > charter discussions. > > If you want to avoid those discussions then simply take the statements > out. They are not necessary. > > On Thu, Aug 19, 2010 at 2:16 PM, Richard L. Barnes > wrote: >> I disagree with the objective and problem statement here; the >> objective is >> too vague, and the problem statement seems completely unrelated. I >> actually >> started out writing the email not intending to write a new charter, >> but >> here's another proposal: >> >> Objective: >> >> Specify mechanisms for Internet applications to use information >> distributed >> through the DNS to establish cryptographically assured bindings >> between >> domain names and public keys. >> >> Problem Statement: >> >> Many Internet applications require protocol entities to >> authenticate that >> they represent a certain domain name. For instance, in HTTPS, a >> server >> responding to a query for is expected to >> authenticate as "www.example.com". Security protocols such as TLS >> and IPsec >> accomplish this authentication by allowing an endpoint to prove >> ownership of >> a private key whose corresponding public key is somehow bound to >> the name >> being authenticated. As a pre-requisite for authentication, then, >> these >> protocols require a mechanism for bindings to be asserted between >> public >> keys and domain names. >> >> In the past, these bindings have been asserted by parties external >> to the >> DNS, using X.509 certificates. A certification authority (CA) can >> create >> certificates that contain a domain name (e.g., as a Common Name or >> dNSName >> Subject Alternative Name) and a public key. When a server presents >> this >> certificate and proves ownership of the private key, a relying >> party that >> trusts the CA to authenticate domain ownership can be assured that >> the >> server legitimately represents the domain. >> >> One problem with this model is that the CAs that are typically used >> have no >> relationship to the DNS infrastructure about which they are making >> assertions. Modern browsers and operating systems typically >> include more >> than a hundred CAs as trust anchors, any of which can create a >> certificate >> for any domain name. >> >> DNSSEC provides a mechanism for a domain operator to sign DNS >> information >> directly, using keys that are bound to the domain by the parent >> domain; >> relying parties can continue this chain up to any trust anchor that >> they >> accept. In this way, bindings of keys to domains are asserted not by >> external entities, but by the entities that operate the DNS. In >> addition to >> providing a more authoritative way of binding DNS names to keys, this >> technique inherently limits the scope of any given entity to the >> names in >> zones he controls. >> >> This working group will develop mechanisms for domain operators to >> present >> bindings between names within their control and public keys, in >> such a way >> that these bindings can be integrity-protected (and thus shown to be >> authentically from the domain operator) using DNSSEC and used as a >> basis for >> authentication in protocols that use domain names as identifiers. >> The group >> may also specify updates or clarifications to protocols to describe >> how >> protocol entities discover and validate these bindings in the >> execution of a >> specific application. >> >> Note that this working group is specifically focused on bindings >> between >> domain names and public keys, rather than bindings between names >> and other >> sorts of information. For example, an X.509 certificate can >> associate many >> types of information with its subject, including things like IP >> address >> holdings and images of logos, as well as bindings to higher-layer >> identities >> (e.g., corporate names). Mechanisms developed by this group will >> not be >> focused on these additional data, only on public keys. This basic >> binding >> might be used, however, to associate a domain name with rich data by >> including the same public key in the certificate that is bound to the >> domain. >> >> >> >> >> >> >> >> >> >> On Aug 19, 2010, at 1:12 PM, Phillip Hallam-Baker wrote: >> >>> In response to Paul's request, I propose the following as a better >>> statement of what the group is trying to do and to not do. >>> >>> >>> Objective: >>> >>> Specify mechanisms that allow Internet applications to establish >>> cryptographically enhanced communications through use of information >>> distributed through the DNS. >>> >>> Problem Statement: >>> >>> Today the Internet is insecure by default and security is the >>> exception. If the security of the Internet is to be improved, >>> security >>> must become the default. In particular modern computers have the >>> ability to employ cryptographic security enhancements with minimal >>> or >>> negligible impact on performance, yet only a tiny proportion of >>> Internet traffic is encrypted or authenticated. >>> >>> One of the key weaknesses of the current Internet Public Key >>> Infrastructure (PKI) is that the most widely used Internet PKI is >>> based on the X.500 Directory scheme intended to support an entirely >>> different networking infrastructure. >>> >>> The naming infrastructure of the Internet is the DNS, not X.500. >>> While >>> the PKIX specifications provide a means of mapping X.509v3 >>> attributes >>> to DNS names there is currently no widely accepted, generalized >>> means >>> of achieving the mapping from DNS names to X.509 certificates in >>> particular or to cryptographic keying material in general. DKIM and >>> SSH have demonstrated the utility of this approach in specific >>> domains, these specifications >>> >>> Recent progress in deployment of DNSSEC has renewed focus on the use >>> of the DNS naming system to support cryptographic operations. In >>> particular: >>> >>> * Discovery of keying material by DNS name >>> * Discovery of security criteria by DNS names >>> * Verification of keying material through DNSSEC trust chains >>> >>> Scope: >>> >>> * Use of existing security protocols with DNS established keys >>> * Use of DNS to verify existing certificate / keysigning / security >>> assertion material formats >>> * Means of verifying key/certificate chains using DNSSEC >>> exclusively >>> * Means of verifying key/certificate chains using DNSSEC in >>> combination with other existing means >>> >>> Out-Of-Scope: >>> >>> * Reason for choice of specific trust paths >>> * New formats for keying material (other than raw keys) >>> * New trust architectures (unless they can be expressed in existing >>> formats >>> >>> >>> What I am proposing here is that instead of committing up front to a >>> view of DNSSEC as being intrinsically opposed to existing PKI >>> schemes >>> in that charter, we look for way that we can use DNSSEC and existing >>> infrastructures together. >>> >>> The biggest mistake made in the PKI world was when the PGP and PEM >>> people decided that they could not possibly work together and so >>> they >>> developed to schemes for email security that have competed for >>> mindshare ever since. Jon Callas and I tried to work out ways of >>> overcoming the consequences of that choice on many occasions without >>> much success. The result has been that neither PGP nor SMIME is >>> widely >>> used. >>> >>> >>> -- >>> Website: http://hallambaker.com/ >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >> >> > > > > -- > Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C590D3A697B for ; Thu, 19 Aug 2010 12:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[AWL=1.628, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7p+3GSwmks1 for ; Thu, 19 Aug 2010 12:26:06 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id B2AB43A69AA for ; Thu, 19 Aug 2010 12:26:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=ccoFa76VvKWbRbKF71UjeORTAfBAKnX9ydHwNFBoeL7/LlD1ug4R3CodyZuAEk1O; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OmAl6-0008Gs-Q8; Thu, 19 Aug 2010 15:26:40 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Thu, 19 Aug 2010 15:26:40 -0400 Message-ID: <18690039.1282246000775.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Thu, 19 Aug 2010 14:26:40 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Tony Finch , keyassure@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606886abb1e1fa91303a564de22fdcc8405c9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:26:12 -0000 Tony and all, FWIW, I think this should be a primary goal... -----Original Message----- >From: Tony Finch >Sent: Aug 19, 2010 12:08 PM >To: keyassure@ietf.org >Subject: [keyassure] user keys > >Paul Wouters wrote: >>On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote: >>> >>> In my view user keys do not belong in the DNS because the DNS is an >>> infrastructure for locating network services, not network users. >> >> I disagree. You are locating an identity. Currently, that is mostly done >> based on an IP address and port. I'd hope tomorrow that would mostly be >> done based on a public key or hash. Especially with mobile devices, IP's >> are very volatile. To locate a service or user, we need the DNS. > >Yes. At the moment the PKIs for identifying people are rather cumbersome. >It would be nice to be able to use DNSSEC for verifying S/MIME or PGP >messages. > >Tony. >-- >f.anthony.n.finch http://dotat.at/ >SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD. >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5BEA3A688F for ; Thu, 19 Aug 2010 12:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17QyP3tasndz for ; Thu, 19 Aug 2010 12:19:21 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 194F83A68B2 for ; Thu, 19 Aug 2010 12:19:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id CD524DC5FF6; Thu, 19 Aug 2010 12:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xRcZEuPrgRc; Thu, 19 Aug 2010 12:19:51 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 2C6CCDC5FE6; Thu, 19 Aug 2010 12:19:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <995AC4D8-5370-4E18-96B0-703DDB7D1A80@bbn.com> Date: Thu, 19 Aug 2010 12:19:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <185111DC-53F3-4DB0-A00B-185F30EF3493@bbn.com> <995AC4D8-5370-4E18-96B0-703DDB7D1A80@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1081) Cc: Tony Finch , keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:19:23 -0000 On Aug 19, 2010, at 11:07 AM, Richard L. Barnes wrote: >> In many cases user keys have a username@domain structure so it would = make >> sense for user keys to be signed by a domain key which can in turn be >> validated using the DNS. >=20 > Although many user identifiers have that form superficially, there are = more worms here than you expect. If you're going to be precise and = thorough, you'll need to address the full syntax of the URI scheme = you're considering, which is significantly more complex. =20 Why would you need to deal with the full syntax of a URI? What = scenarios are you imagining that would suggest we can't solve the = username@domain structure? My understanding of the suggestion (which = may be wrong) is signing something like $ORIGIN virtualized.org. drc IN PGPKEY drc IN SMIMEKEY ... > And this is not mentioning things like internationalization... Which isn't a problem since the DNS is 8-bit clean and since you don't = have to worry about backwards compatibility, you could put anything into = the label. The only constraint is the label has to be less than 64 = bytes. > Even if you went to the trouble of defining a mapping, it would just = be an specific way of constructing the names you would use to find keys = for a given type of identifier. Nothing would be different about how = the information is encoded in the DNS. Right. It would just be using the DNS as a distributed tag lookup = system that now returns validatable values. Which is OK since that is = what the DNS is. > Like Paul said, the DNS is about domain names. =20 I honestly don't understand what this means. > A zone is authoritative for the names it contains. If you start = talking about things like email addresses, you have a whole different = way that identifiers are assigned, and the trust model should map along = with that. A whole different way than what? I'd think that if you care about the = trust model mapping to the way the identifiers were assigned, you'd do = zone delegations to make that happen. I'm clearly missing something. Regards, -drc Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323AE3A68AB for ; Thu, 19 Aug 2010 12:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2WBYRjifT60 for ; Thu, 19 Aug 2010 12:17:32 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id DEB703A688F for ; Thu, 19 Aug 2010 12:17:27 -0700 (PDT) Received: by yxk8 with SMTP id 8so1020827yxk.31 for ; Thu, 19 Aug 2010 12:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ryJdpAdGoYAJLvW+nbzvZNtaN3NMSDMY1f5lRm7KBUU=; b=k15kualQAhxAJ4cSG1LXzWH7GMAi9Wr5PpVmcjpacNejBQVCuJNzsOjS2cQcwkfbyk SbhfWdxp12S+TizRv7ODlg6/0qHirUDoXgZa9+ArGeE/EEkVQ1S779rJ9lla1L6XWiSg W4XYizBfJTmgN/eluvZTA2wt/DRtZl9pV+yVU= 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:content-transfer-encoding; b=cEzlHr5b+fH6vbWPIls2HpfHTo+6qz7EmX5RTVruyuOgiz/VpY6rLA61HSysJYSy+Z FDYTn1LSpS8S4IxJGDq8zR4mAS3hk51OVA79qqZd6uY02exqMkWLy0WqofBoi4Fban0T hPpLh5I2Zq4cwLASKbPWzkCw/pW0U3fb6TM2Q= MIME-Version: 1.0 Received: by 10.90.95.7 with SMTP id s7mr414525agb.169.1282245481639; Thu, 19 Aug 2010 12:18:01 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 19 Aug 2010 12:18:01 -0700 (PDT) In-Reply-To: <87B7EB98-3F68-4C0C-9420-5B7D4BDF75D6@bbn.com> References: <87B7EB98-3F68-4C0C-9420-5B7D4BDF75D6@bbn.com> Date: Thu, 19 Aug 2010 15:18:01 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Alternative Charter Proposal X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:17:34 -0000 That is still an architectural statement, not a problem statement. If you want to put statements into the charter asserting the benefit of one particular trust topology, then you have to accept the argument over whether those claims are actually true as being in scope for charter discussions. If you want to avoid those discussions then simply take the statements out. They are not necessary. On Thu, Aug 19, 2010 at 2:16 PM, Richard L. Barnes wrote: > I disagree with the objective and problem statement here; the objective i= s > too vague, and the problem statement seems completely unrelated. =A0I act= ually > started out writing the email not intending to write a new charter, but > here's another proposal: > > Objective: > > Specify mechanisms for Internet applications to use information distribut= ed > through the DNS to establish cryptographically assured bindings between > domain names and public keys. > > Problem Statement: > > Many Internet applications require protocol entities to authenticate that > they represent a certain domain name. =A0For instance, in HTTPS, a server > responding to a query for is expected to > authenticate as "www.example.com". =A0Security protocols such as TLS and = IPsec > accomplish this authentication by allowing an endpoint to prove ownership= of > a private key whose corresponding public key is somehow bound to the name > being authenticated. =A0As a pre-requisite for authentication, then, thes= e > protocols require a mechanism for bindings to be asserted between public > keys and domain names. > > In the past, these bindings have been asserted by parties external to the > DNS, using X.509 certificates. =A0A certification authority (CA) can crea= te > certificates that contain a domain name (e.g., as a Common Name or dNSNam= e > Subject Alternative Name) and a public key. =A0When a server presents thi= s > certificate and proves ownership of the private key, a relying party that > trusts the CA to authenticate domain ownership can be assured that the > server legitimately represents the domain. > > One problem with this model is that the CAs that are typically used have = no > relationship to the DNS infrastructure about which they are making > assertions. =A0Modern browsers and operating systems typically include mo= re > than a hundred CAs as trust anchors, any of which can create a certificat= e > for any domain name. > > DNSSEC provides a mechanism for a domain operator to sign DNS information > directly, using keys that are bound to the domain by the parent domain; > relying parties can continue this chain up to any trust anchor that they > accept. =A0In this way, bindings of keys to domains are asserted not by > external entities, but by the entities that operate the DNS. =A0In additi= on to > providing a more authoritative way of binding DNS names to keys, this > technique inherently limits the scope of any given entity to the names in > zones he controls. > > This working group will develop mechanisms for domain operators to presen= t > bindings between names within their control and public keys, in such a wa= y > that these bindings can be integrity-protected (and thus shown to be > authentically from the domain operator) using DNSSEC and used as a basis = for > authentication in protocols that use domain names as identifiers. =A0The = group > may also specify updates or clarifications to protocols to describe how > protocol entities discover and validate these bindings in the execution o= f a > specific application. > > Note that this working group is specifically focused on bindings between > domain names and public keys, rather than bindings between names and othe= r > sorts of information. =A0For example, an X.509 certificate can associate = many > types of information with its subject, including things like IP address > holdings and images of logos, as well as bindings to higher-layer identit= ies > (e.g., corporate names). =A0Mechanisms developed by this group will not b= e > focused on these additional data, only on public keys. =A0This basic bind= ing > might be used, however, to associate a domain name with rich data by > including the same public key in the certificate that is bound to the > domain. > > > > > > > > > > On Aug 19, 2010, at 1:12 PM, Phillip Hallam-Baker wrote: > >> In response to Paul's request, I propose the following as a better >> statement of what the group is trying to do and to not do. >> >> >> Objective: >> >> Specify mechanisms that allow Internet applications to establish >> cryptographically enhanced communications through use of information >> distributed through the DNS. >> >> Problem Statement: >> >> Today the Internet is insecure by default and security is the >> exception. If the security of the Internet is to be improved, security >> must become the default. In particular modern computers have the >> ability to employ cryptographic security enhancements with minimal or >> negligible impact on performance, yet only a tiny proportion of >> Internet traffic is encrypted or authenticated. >> >> One of the key weaknesses of the current Internet Public Key >> Infrastructure (PKI) is that the most widely used Internet PKI is >> based on the X.500 Directory scheme intended to support an entirely >> different networking infrastructure. >> >> The naming infrastructure of the Internet is the DNS, not X.500. While >> the PKIX specifications provide a means of mapping X.509v3 attributes >> to DNS names there is currently no widely accepted, generalized means >> of achieving the mapping from DNS names to X.509 certificates in >> particular or to cryptographic keying material in general. DKIM and >> SSH have demonstrated the utility of this approach in specific >> domains, these specifications >> >> Recent progress in deployment of DNSSEC has renewed focus on the use >> of the DNS naming system to support cryptographic operations. In >> particular: >> >> =A0* Discovery of keying material by DNS name >> =A0* Discovery of security criteria by DNS names >> =A0* Verification of keying material through DNSSEC trust chains >> >> Scope: >> >> =A0* Use of existing security protocols with DNS established keys >> =A0* Use of DNS to verify existing certificate / keysigning / security >> assertion material formats >> =A0* Means of verifying key/certificate chains using DNSSEC exclusively >> =A0* Means of verifying key/certificate chains using DNSSEC in >> combination with other existing means >> >> Out-Of-Scope: >> >> * Reason for choice of specific trust paths >> * New formats for keying material (other than raw keys) >> * New trust architectures (unless they can be expressed in existing >> formats >> >> >> What I am proposing here is that instead of committing up front to a >> view of DNSSEC as being intrinsically opposed to existing PKI schemes >> in that charter, we look for way that we can use DNSSEC and existing >> infrastructures together. >> >> The biggest mistake made in the PKI world was when the PGP and PEM >> people decided that they could not possibly work together and so they >> developed to schemes for email security that have competed for >> mindshare ever since. Jon Callas and I tried to work out ways of >> overcoming the consequences of that choice on many occasions without >> much success. The result has been that neither PGP nor SMIME is widely >> used. >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44FD23A6842 for ; Thu, 19 Aug 2010 11:59:19 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0n5MHXv6KXt for ; Thu, 19 Aug 2010 11:59:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 615783A68D0 for ; Thu, 19 Aug 2010 11:59:18 -0700 (PDT) Received: from [192.1.255.185] (port=53129 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmALB-00007o-3M; Thu, 19 Aug 2010 14:59:53 -0400 Message-Id: <3F58115D-9CF1-4CE2-8AD2-A9E1B0A1807D@bbn.com> From: "Richard L. Barnes" To: Tony Finch In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 14:59:52 -0400 References: <185111DC-53F3-4DB0-A00B-185F30EF3493@bbn.com> <995AC4D8-5370-4E18-96B0-703DDB7D1A80@bbn.com> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:59:19 -0000 Ok, but if you're representing users as domain names, then you're just doing the same thing as you're doing for any other domain name, and it's not interesting any more. On Aug 19, 2010, at 2:58 PM, Tony Finch wrote: > On Thu, 19 Aug 2010, Richard L. Barnes wrote: >> >>>> It seems like it would be a big enough win for this group to come >>>> up with a better way of binding keys to domain names. >>> >>> That sounds like an argument for putting user keys in the DNS. >> >> Not sure how that follows? > > See below. I was facetiously pointing out that two adjacent sentences > seemed to contradict each other. I don't think "domain name" rules out > "user identifier represented as a domain name". For example several > ISPs > create a domain per user, and some sites shard their mail services > with > per-user service host names. > >>> Sorry for being argumentative but you need to be clear about where >>> and why >>> you are drawing a line :-) > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC > 7 TO > SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH > BECOMING VERY > ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15EA3A6993 for ; Thu, 19 Aug 2010 11:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D--JmbrvfVgn for ; Thu, 19 Aug 2010 11:58:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id B12E13A6862 for ; Thu, 19 Aug 2010 11:58:21 -0700 (PDT) Received: from [192.1.255.185] (port=53129 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmAKG-00007o-B6; Thu, 19 Aug 2010 14:58:56 -0400 Message-Id: From: "Richard L. Barnes" To: Tony Finch In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 14:58:55 -0400 References: X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] signalling use of crypto as well as service keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:58:22 -0000 These are not DNS problems or TLS problems, hence out of scope for this group. >> * there is no way to know if the web site uses ssl This is being discussed in the HASMAT group. See, for example: >> * there is no way to know if the recipient can accept smime >> * there is no way to find an smime recipient cert that is widely >> supported DNS is not the proper mechanism for distributing information of this character, since it's bound to email addresses, not domain names. > The cause of the problem was that it was never specified what the TLS > certificate identifies in SMTP: hostname? mail domain? and at the time > there was no way to signal to a mail server what certificate the > client > expected. As a result mail server certificates are never validated > so most > of them present certificates that cannot be validated since any old > cert > will work. > > The only way to fix this is to clearly specify how authentication must > work, and add some kind of signal so the server can indicate that it > supports this spec and so clients should be able to authenticate it. The fact that SMTP has a poorly specified security mechanism is not something for this group. That would be an APPAREA group that would update the SMTP specs to do proper server identity checking. > One of the key differences between the web and SMTP is the extra > indirection in MX records. SRV records have the same property. This > is a > great boon for virtual hosting - it's so normal for a mail server to > host > multiple mail domains that it isn't even called virtual hosting. > It's also > normal for a mail domain's DNS, primary, and backup MXs to be hosted > by > three or more different organizations. > > If the DNS associates keys directly with a mail domain [1] then > there's a > coupling problem between the DNS host and the application host: an > app key > rollover will require updating hundreds of domains which may be > hosted by > many third parties. If the DNS associates keys with host names (i.e. > the > targets of MX records) then we have to think very carefully about the > security properties of that indirection, since normally we want to > directly secure the identity that the user sees. The underlying problem here is that MX records aren't authenticated. If they are, then you just do the same thing as with the web and authenticate against the server's host name; if not, then you have to authenticate against the mail domain. This is exactly the problem discussed in these drafts... ... and it goes away if you have DNSSEC. So it's really not germane here, where we're starting with the assumption of DNSSEC. > Nicholas Weaver has also been talking about the next layer of > indirection, > associating keys with IP addresses. I'm doubtful that this would be > useful > since it is even further from securing the identity that the user > sees, > and it does not have obvious vhosting benefits. On this at least we agree :) Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513F73A68D0 for ; Thu, 19 Aug 2010 11:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.471 X-Spam-Level: X-Spam-Status: No, score=-5.471 tagged_above=-999 required=5 tests=[AWL=1.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDIOeFYLTPzZ for ; Thu, 19 Aug 2010 11:58:10 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) by core3.amsl.com (Postfix) with ESMTP id 0E86C3A6862 for ; Thu, 19 Aug 2010 11:58:10 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:34711) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1OmAK4-0004H0-gu (Exim 4.72) (return-path ); Thu, 19 Aug 2010 19:58:44 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OmAK4-0005Pb-9F (Exim 4.67) (return-path ); Thu, 19 Aug 2010 19:58:44 +0100 Date: Thu, 19 Aug 2010 19:58:44 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Richard L. Barnes" In-Reply-To: <995AC4D8-5370-4E18-96B0-703DDB7D1A80@bbn.com> Message-ID: References: <185111DC-53F3-4DB0-A00B-185F30EF3493@bbn.com> <995AC4D8-5370-4E18-96B0-703DDB7D1A80@bbn.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:58:11 -0000 On Thu, 19 Aug 2010, Richard L. Barnes wrote: > > > > It seems like it would be a big enough win for this group to come > > > up with a better way of binding keys to domain names. > > > > That sounds like an argument for putting user keys in the DNS. > > Not sure how that follows? See below. I was facetiously pointing out that two adjacent sentences seemed to contradict each other. I don't think "domain name" rules out "user identifier represented as a domain name". For example several ISPs create a domain per user, and some sites shard their mail services with per-user service host names. > > Sorry for being argumentative but you need to be clear about where and why > > you are drawing a line :-) Tony. -- f.anthony.n.finch http://dotat.at/ ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH BECOMING VERY ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751583A6844 for ; Thu, 19 Aug 2010 11:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.146 X-Spam-Level: X-Spam-Status: No, score=-5.146 tagged_above=-999 required=5 tests=[AWL=0.853, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtvfxVApWqjz for ; Thu, 19 Aug 2010 11:42:28 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) by core3.amsl.com (Postfix) with ESMTP id 0BCFD3A67D0 for ; Thu, 19 Aug 2010 11:42:28 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51329) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1OmA4s-0000nI-iH (Exim 4.72) for keyassure@ietf.org (return-path ); Thu, 19 Aug 2010 19:43:02 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OmA4s-0003bi-N8 (Exim 4.67) for keyassure@ietf.org (return-path ); Thu, 19 Aug 2010 19:43:02 +0100 Date: Thu, 19 Aug 2010 19:43:02 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: keyassure@ietf.org Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [keyassure] signalling use of crypto as well as service keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:42:29 -0000 Phillip Hallam-Baker > > At the moment the biggest holes in smime and ssl are > > * there is no way to know if the web site uses ssl > * there is no way to know if the recipient can accept smime > * there is no way to find an smime recipient cert that is widely supported > > All of these stem from the fact that x.509 certs are not properly > integrated into dns. And those are the areas where I see big potential > for creating a unique value for dnssec. Yes. This is a particular problem for SMTP. There is no certificate verification in inter-domain SMTP+TLS, so the crypto doesn't provide much benefit. The cause of the problem was that it was never specified what the TLS certificate identifies in SMTP: hostname? mail domain? and at the time there was no way to signal to a mail server what certificate the client expected. As a result mail server certificates are never validated so most of them present certificates that cannot be validated since any old cert will work. The only way to fix this is to clearly specify how authentication must work, and add some kind of signal so the server can indicate that it supports this spec and so clients should be able to authenticate it. One of the key differences between the web and SMTP is the extra indirection in MX records. SRV records have the same property. This is a great boon for virtual hosting - it's so normal for a mail server to host multiple mail domains that it isn't even called virtual hosting. It's also normal for a mail domain's DNS, primary, and backup MXs to be hosted by three or more different organizations. If the DNS associates keys directly with a mail domain [1] then there's a coupling problem between the DNS host and the application host: an app key rollover will require updating hundreds of domains which may be hosted by many third parties. If the DNS associates keys with host names (i.e. the targets of MX records) then we have to think very carefully about the security properties of that indirection, since normally we want to directly secure the identity that the user sees. Perhaps the policy RR should be associated with the mail domain, but the app key RR should be associated with the host name. This also deals with the problem of backup MX keys. [1] I'm being concrete for simplicity but you can replace "mail domain" with your favourite application identity. Nicholas Weaver has also been talking about the next layer of indirection, associating keys with IP addresses. I'm doubtful that this would be useful since it is even further from securing the identity that the user sees, and it does not have obvious vhosting benefits. Tony. -- f.anthony.n.finch http://dotat.at/ SOUTHEAST ICELAND: NORTHEASTERLY 6 TO GALE 8. ROUGH OR VERY ROUGH. RAIN. GOOD, OCCASIONALLY POOR. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEEF03A6844 for ; Thu, 19 Aug 2010 11:41:40 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOgOWS5r0YZS for ; Thu, 19 Aug 2010 11:41:38 -0700 (PDT) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 092B73A6782 for ; Thu, 19 Aug 2010 11:41:37 -0700 (PDT) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id o7JIgB2k008855; Thu, 19 Aug 2010 11:42:11 -0700 Received: from MOU1WNEXMB03.vcorp.ad.vrsn.com ([10.25.13.156]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Aug 2010 11:42:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Aug 2010 11:42:10 -0700 Message-ID: In-Reply-To: <29260948.1282166689320.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [keyassure] Charter discussion - Use of DNSSEC in applications Thread-Index: Acs/HPtyEByI1Hc8RyGe3HguS7hIhQAsD65w References: <29260948.1282166689320.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> From: "Doreswamy, Rangan" To: "Jeffrey A. Williams" , "Phillip Hallam-Baker" , "Andrew Sullivan" X-OriginalArrivalTime: 19 Aug 2010 18:42:09.0818 (UTC) FILETIME=[3B2367A0:01CB3FCE] X-Mailman-Approved-At: Thu, 19 Aug 2010 13:07:51 -0700 Cc: william.barker@nist.gov, keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:41:41 -0000 If the reference is to the Code signing certificates that appear to be = stolen VeriSign Code Signing certificates I would like to highlight that = no VeriSign infrastructure was compromised or any key material was = stolen from VeriSign's systems. We became aware of both these attacks = when they were reported in the press, and both of the certificates = involved are revoked. Each certificate holder was fully cooperative and = understanding about the need to revoke the certificates in question. = We're looking at potential methods of predicting certificates that may = be compromised and therefore used in subsequent attacks and then = encouraging preemptive replacement by the holders of those certificates. = Microsoft has issued an advisory on the Windows flaw and states it's = working on a fix.=20 Thanks, RD rd_doreswamy@symantec.com -----Original Message----- From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On = Behalf Of Jeffrey A. Williams Sent: Wednesday, August 18, 2010 2:25 PM To: Phillip Hallam-Baker; Andrew Sullivan Cc: william.barker@nist.gov; keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in = applications Phillip and all, FWIW, I am not sure I would trust a cert signed by Verisign right now given that recently their=20 Cert database was hacked/breached and I have no independant assurance that Verisign has 'fixed' that breach adaquately and/or informed 'All' of its Cert customers accordingly. None the less, Verisign produces good Certs, so the question than becomes=20 is the user of that Cert now the correct one and how does anyone know that for sure? -----Original Message----- >From: Phillip Hallam-Baker >Sent: Aug 18, 2010 2:55 PM >To: Andrew Sullivan >Cc: keyassure@ietf.org >Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in = applications > >On Wed, Aug 18, 2010 at 12:39 PM, Andrew Sullivan = wrote: >>> >>> 1 - DNSSEC can tell me who owns some DNS data, like an assertion = about >>> a hostname. =A0I don't think I know any more than that. =A0That's = pretty >>> important, but >>> >>> 2 - X.509 certificates could tell me a lot more about what I can = expect >>> from the transaction I am starting. =A0It can deliver a level of = assurance >>> attribute, a policy pointer of some kind that can lead to a complete >>> disclosure of what this certificate means, and other attributes that >>> describe what this certificate is supposed to permit or deny. =A0I = don't >>> think this is available in DNSSEC. =A0We can argue about the utility = of >>> some of this but that's not the issue. >>> >>> Another way of looking at it - this should be up the stack & closer = to >>> the application's viewpoint than DNS is (should be). =A0So perhaps >> >> It seems to me that this distinction is one on which we foundered >> during the BOF, too. >> >> There are two completely different use cases for TLS, and we will get >> nowhere if we assert that solutions for one are inadequate solutions >> for the other. >> >> The goal in the current keys-linkage draft, as I read it, is simply = to >> gain some assurance that the PKIX cert in question is actually >> associated with the domain it claims to be. =A0That is by no means = any >> kind of assurance that (say) the domain is actually operated by the >> organization one thinks it is (i.e. it doesn't prove that >> www.mybank.com is actually operated by My Bank, member FDIC). > >With DNSSEC alone we have a domain linkage, but no accountability for = it. > >With DV we have a measure of accountability in that CAs that really >screw up could in theory be dumped out of the browsers and we have >defined and audited processes. > >With EV we have an industry standard assurance level and audited = process. > >Now we could have a pointless discussion about whether DV is really >more secure than DNSSEC, but I think thats pointless as I don't think >anyone is willing to state that either is a sufficient basis for >handing over your credit card number or doing banking. And so neither >should merit a padlock icon. > > >> The first of those is not too far from your (1) (but I think your >> description doesn't quite capture the power of being able to = guarantee >> you got the right result from the DNS). =A0The second of these is >> plainly related to your (2). >> >> The fact is that many people think (2) is a waste of time for many >> purposes: many of the actual CAs simply don't do anything like the = job >> necessary to believe their assertions about identity and so on >> embodied in the cert. =A0Therefore, the "utility of some of this" is = not >> the issue directly, but it certainly is a motivating factor in the >> discussion. =A0I don't think we can dismiss it. =A0If the facilities = that >> are supposed to be offered by a technology don't work in practice, >> then the lack of utility is relevant to rhe duscussion. =A0(This is = not >> to say the facilities are never useful. =A0But as general >> infrastructure, they haven't worked out so well in terms of actually >> identifying complete strangers to one anhother.) > >One big problem here, one that I did insist we deal with in EV was to >actually show who is providing the certificate to the end user. A >green bar from a VeriSign or a Comodo may not mean the same to the end >user as a green bar from Bogocert CA they never heard of before. > >The importance of this distinction was just demonstrated in the UAE >case. Perhaps people are not going to want to trust CAs in certain >parts of the world for certain purposes. I would not accept code >signed with a cert from a Nigerian, Sudanese or Russian CA. > > > >--=20 >Website: http://hallambaker.com/ >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and = growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; = liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. = of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail = jwkckid1@ix.netcom.com Phone: 214-244-4827 _______________________________________________ keyassure mailing list keyassure@ietf.org https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7753A6899 for ; Thu, 19 Aug 2010 11:16:21 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uyi7hgMeCtOS for ; Thu, 19 Aug 2010 11:16:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A63513A6801 for ; Thu, 19 Aug 2010 11:16:14 -0700 (PDT) Received: from [192.1.255.185] (port=52752 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Om9fT-000DLv-ED; Thu, 19 Aug 2010 14:16:47 -0400 Message-Id: <87B7EB98-3F68-4C0C-9420-5B7D4BDF75D6@bbn.com> From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 14:16:46 -0400 References: X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Alternative Charter Proposal X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:16:21 -0000 I disagree with the objective and problem statement here; the objective is too vague, and the problem statement seems completely unrelated. I actually started out writing the email not intending to write a new charter, but here's another proposal: Objective: Specify mechanisms for Internet applications to use information distributed through the DNS to establish cryptographically assured bindings between domain names and public keys. Problem Statement: Many Internet applications require protocol entities to authenticate that they represent a certain domain name. For instance, in HTTPS, a server responding to a query for is expected to authenticate as "www.example.com". Security protocols such as TLS and IPsec accomplish this authentication by allowing an endpoint to prove ownership of a private key whose corresponding public key is somehow bound to the name being authenticated. As a pre-requisite for authentication, then, these protocols require a mechanism for bindings to be asserted between public keys and domain names. In the past, these bindings have been asserted by parties external to the DNS, using X.509 certificates. A certification authority (CA) can create certificates that contain a domain name (e.g., as a Common Name or dNSName Subject Alternative Name) and a public key. When a server presents this certificate and proves ownership of the private key, a relying party that trusts the CA to authenticate domain ownership can be assured that the server legitimately represents the domain. One problem with this model is that the CAs that are typically used have no relationship to the DNS infrastructure about which they are making assertions. Modern browsers and operating systems typically include more than a hundred CAs as trust anchors, any of which can create a certificate for any domain name. DNSSEC provides a mechanism for a domain operator to sign DNS information directly, using keys that are bound to the domain by the parent domain; relying parties can continue this chain up to any trust anchor that they accept. In this way, bindings of keys to domains are asserted not by external entities, but by the entities that operate the DNS. In addition to providing a more authoritative way of binding DNS names to keys, this technique inherently limits the scope of any given entity to the names in zones he controls. This working group will develop mechanisms for domain operators to present bindings between names within their control and public keys, in such a way that these bindings can be integrity-protected (and thus shown to be authentically from the domain operator) using DNSSEC and used as a basis for authentication in protocols that use domain names as identifiers. The group may also specify updates or clarifications to protocols to describe how protocol entities discover and validate these bindings in the execution of a specific application. Note that this working group is specifically focused on bindings between domain names and public keys, rather than bindings between names and other sorts of information. For example, an X.509 certificate can associate many types of information with its subject, including things like IP address holdings and images of logos, as well as bindings to higher-layer identities (e.g., corporate names). Mechanisms developed by this group will not be focused on these additional data, only on public keys. This basic binding might be used, however, to associate a domain name with rich data by including the same public key in the certificate that is bound to the domain. On Aug 19, 2010, at 1:12 PM, Phillip Hallam-Baker wrote: > In response to Paul's request, I propose the following as a better > statement of what the group is trying to do and to not do. > > > Objective: > > Specify mechanisms that allow Internet applications to establish > cryptographically enhanced communications through use of information > distributed through the DNS. > > Problem Statement: > > Today the Internet is insecure by default and security is the > exception. If the security of the Internet is to be improved, security > must become the default. In particular modern computers have the > ability to employ cryptographic security enhancements with minimal or > negligible impact on performance, yet only a tiny proportion of > Internet traffic is encrypted or authenticated. > > One of the key weaknesses of the current Internet Public Key > Infrastructure (PKI) is that the most widely used Internet PKI is > based on the X.500 Directory scheme intended to support an entirely > different networking infrastructure. > > The naming infrastructure of the Internet is the DNS, not X.500. While > the PKIX specifications provide a means of mapping X.509v3 attributes > to DNS names there is currently no widely accepted, generalized means > of achieving the mapping from DNS names to X.509 certificates in > particular or to cryptographic keying material in general. DKIM and > SSH have demonstrated the utility of this approach in specific > domains, these specifications > > Recent progress in deployment of DNSSEC has renewed focus on the use > of the DNS naming system to support cryptographic operations. In > particular: > > * Discovery of keying material by DNS name > * Discovery of security criteria by DNS names > * Verification of keying material through DNSSEC trust chains > > Scope: > > * Use of existing security protocols with DNS established keys > * Use of DNS to verify existing certificate / keysigning / security > assertion material formats > * Means of verifying key/certificate chains using DNSSEC exclusively > * Means of verifying key/certificate chains using DNSSEC in > combination with other existing means > > Out-Of-Scope: > > * Reason for choice of specific trust paths > * New formats for keying material (other than raw keys) > * New trust architectures (unless they can be expressed in existing > formats > > > What I am proposing here is that instead of committing up front to a > view of DNSSEC as being intrinsically opposed to existing PKI schemes > in that charter, we look for way that we can use DNSSEC and existing > infrastructures together. > > The biggest mistake made in the PKI world was when the PGP and PEM > people decided that they could not possibly work together and so they > developed to schemes for email security that have competed for > mindshare ever since. Jon Callas and I tried to work out ways of > overcoming the consequences of that choice on many occasions without > much success. The result has been that neither PGP nor SMIME is widely > used. > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E348F3A6844 for ; Thu, 19 Aug 2010 11:06:38 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msdq9FnjDaQh for ; Thu, 19 Aug 2010 11:06:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 0A2853A69E1 for ; Thu, 19 Aug 2010 11:06:34 -0700 (PDT) Received: from [192.1.255.185] (port=52701 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Om9W8-000D5e-CB; Thu, 19 Aug 2010 14:07:08 -0400 Message-Id: <995AC4D8-5370-4E18-96B0-703DDB7D1A80@bbn.com> From: "Richard L. Barnes" To: Tony Finch In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 14:07:06 -0400 References: <185111DC-53F3-4DB0-A00B-185F30EF3493@bbn.com> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:06:39 -0000 >> This seems like a bad path to be headed down. There are lots of >> identifiers >> that can be tied to public keys: email addresses, SIP URIs, >> telephone numbers, >> childhood nicknames. It would be a mistake to try to smash them >> all into the >> DNS. > > In many cases user keys have a username@domain structure so it would > make > sense for user keys to be signed by a domain key which can in turn be > validated using the DNS. Although many user identifiers have that form superficially, there are more worms here than you expect. If you're going to be precise and thorough, you'll need to address the full syntax of the URI scheme you're considering, which is significantly more complex. And this is not mentioning things like internationalization... Even if you went to the trouble of defining a mapping, it would just be an specific way of constructing the names you would use to find keys for a given type of identifier. Nothing would be different about how the information is encoded in the DNS. >> Authenticating identifiers from other protocols should be the job >> of those >> protocols. > > That sounds like an argument for leaving TLS as it currently is. Like Paul said, the DNS is about domain names. A zone is authoritative for the names it contains. If you start talking about things like email addresses, you have a whole different way that identifiers are assigned, and the trust model should map along with that. >> It seems like it would be a big enough win for this group to come >> up with a better way of binding keys to domain names. > > That sounds like an argument for putting user keys in the DNS. Not sure how that follows? --Richard > > Sorry for being argumentative but you need to be clear about where > and why > you are drawing a line :-) > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > HEBRIDES: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 6 TO > GALE 8 > LATER. ROUGH. SHOWERS, RAIN LATER. MODERATE OR GOOD. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF95B3A686C for ; Thu, 19 Aug 2010 11:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.411 X-Spam-Level: X-Spam-Status: No, score=-5.411 tagged_above=-999 required=5 tests=[AWL=1.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSMXKCVtkp+q for ; Thu, 19 Aug 2010 11:02:16 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) by core3.amsl.com (Postfix) with ESMTP id 173323A6847 for ; Thu, 19 Aug 2010 11:02:16 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:34816) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Om9Ry-0000sM-eJ (Exim 4.72) (return-path ); Thu, 19 Aug 2010 19:02:50 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Om9Ry-0007RT-FW (Exim 4.67) (return-path ); Thu, 19 Aug 2010 19:02:50 +0100 Date: Thu, 19 Aug 2010 19:02:50 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: keyassure@ietf.org Subject: Re: [keyassure] multi-application certificate RRs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:02:18 -0000 On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote: > I would hope that if we get people to start using DNS for their keying > material that there would also be more widespread use of SRV. > Wouldn't it make sense to use the exact same approach for the protocol > specific keying information? RFC 5507 argues against SRV-style name prefixes because they interact badly with wildcards. On the other hand it is rather complacent about RR type exhaustion. Tony. -- f.anthony.n.finch http://dotat.at/ SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32EFC3A6899 for ; Thu, 19 Aug 2010 10:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.374 X-Spam-Level: X-Spam-Status: No, score=-5.374 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdVcR9LtF8bD for ; Thu, 19 Aug 2010 10:54:30 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) by core3.amsl.com (Postfix) with ESMTP id 1EC183A67FD for ; Thu, 19 Aug 2010 10:54:30 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:40057) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Om9KS-00075E-fK (Exim 4.72) (return-path ); Thu, 19 Aug 2010 18:55:04 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Om9KS-0006U9-PZ (Exim 4.67) (return-path ); Thu, 19 Aug 2010 18:55:04 +0100 Date: Thu, 19 Aug 2010 18:55:04 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: <19F4493A-6E3E-418F-9643-1F8D578C3C20@gmail.com> Message-ID: References: <50A38D0D-8F66-4A8B-836A-9C8A5C0F9280@bbn.com> <19F4493A-6E3E-418F-9643-1F8D578C3C20@gmail.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "keyassure@ietf.org" Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:54:31 -0000 On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote: > On Aug 19, 2010, at 1:39 PM, Tony Finch wrote: > > > > Who buys multiple certificates when they only need one? > > People who read their terms of service? :-) IME, though one might need to buy a licence to use a certificate on multiple hosts, this does not mean one needs multiple certificates associated with multiple private keys. Tony. -- f.anthony.n.finch http://dotat.at/ IRISH SEA: SOUTHEAST, VEERING SOUTH 5 TO 7, OCCASIONALLY GALE 8. MODERATE OR ROUGH. RAIN THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4173A6A46 for ; Thu, 19 Aug 2010 10:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.335 X-Spam-Level: X-Spam-Status: No, score=-5.335 tagged_above=-999 required=5 tests=[AWL=1.264, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0TxDenx1bk2 for ; Thu, 19 Aug 2010 10:51:14 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) by core3.amsl.com (Postfix) with ESMTP id 5F7663A6A47 for ; Thu, 19 Aug 2010 10:51:14 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39523) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Om9HH-0006hZ-1C (Exim 4.72) (return-path ); Thu, 19 Aug 2010 18:51:47 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Om9HH-00062v-Bc (Exim 4.67) (return-path ); Thu, 19 Aug 2010 18:51:47 +0100 Date: Thu, 19 Aug 2010 18:51:47 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Nicholas Weaver In-Reply-To: <3C80DCF9-46B6-4714-83F5-1DE5243B93E2@icsi.berkeley.edu> Message-ID: References: <3C80DCF9-46B6-4714-83F5-1DE5243B93E2@icsi.berkeley.edu> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: keyassure@ietf.org Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:51:15 -0000 On Thu, 19 Aug 2010, Nicholas Weaver wrote: > > However, service should be identified by both hostname AND IP address > depending on the server's preference, thus any scheme that says > > _keymaterial_.host.mydomain.com as a query should also include a query for > > _keymaterial_.{A/AAAA record for host.mydomain.com}, IFF the reference > for _keymaterial_.host.mydomain.com says that IP should be referred OR > the service was contacted based on IP rather than hostname. Could you explain why you think this is necessary? TLS doesn't currently bind names and addresses in this way, and doing so makes services less mobile than they could be. Tony. -- f.anthony.n.finch http://dotat.at/ HEBRIDES: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 6 TO GALE 8 LATER. ROUGH. SHOWERS, RAIN LATER. MODERATE OR GOOD. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153CA3A69EB for ; Thu, 19 Aug 2010 10:51:12 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjrhPw1b0mqG for ; Thu, 19 Aug 2010 10:51:10 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id A35F13A6974 for ; Thu, 19 Aug 2010 10:51:10 -0700 (PDT) Received: by qyk1 with SMTP id 1so3344551qyk.10 for ; Thu, 19 Aug 2010 10:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=7qoyBvYNnaZVUnlQ4dLPtZZOQjLWDzEon9w/O108EcI=; b=dwgLq+Wc54Iwa1BRaPE1118bZ7M0tNr806Ij701HNvNi8iCliIdZE5zXBpjHhhfSDo zAmYAPHkOBed1j4xz43d8U846YktCLVA0FHdjAj9riMYO4db9V5imDCd4MfXG0dSLlRu wE+KpyKvDBk5AzyxUd/7vL/a0AlkiVuT8sH+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=BZnvmfacAe/Wtp0MOtGhWSzlO/VxQJ59HW8IAzEl6QdHhaAx0eN5WNXArPDk+d29gf GTEORqYHMvPmKBpHnH6WhyeZ05MAVkVGOMV2eAnCTHScaa6pq3zoC37SSKaRGOopLhvy s7ZqqKEILt8IBgOoRPYAmTAvSgZZgRFjMeRfg= Received: by 10.224.18.99 with SMTP id v35mr98570qaa.355.1282240305023; Thu, 19 Aug 2010 10:51:45 -0700 (PDT) Received: from [10.0.1.8] (c-24-128-190-234.hsd1.ma.comcast.net [24.128.190.234]) by mx.google.com with ESMTPS id t1sm1979808qcs.45.2010.08.19.10.51.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 10:51:44 -0700 (PDT) References: <50A38D0D-8F66-4A8B-836A-9C8A5C0F9280@bbn.com> Message-Id: <19F4493A-6E3E-418F-9643-1F8D578C3C20@gmail.com> From: Phillip Hallam-Baker To: Tony Finch In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Thu, 19 Aug 2010 13:51:43 -0400 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:51:12 -0000 People who read their terms of service? Sent from my iPad On Aug 19, 2010, at 1:39 PM, Tony Finch wrote: > On Thu, 19 Aug 2010, Richard L. Barnes wrote: >> >> Not true. In TLS connection establishment, the server only presents one >> key/cert, but different servers for the same domain can present different >> keys/certs. > > Who buys multiple certificates when they only need one? > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > CROMARTY FORTH TYNE: SOUTH OR SOUTHEAST, 4 OR 5, OCCASIONALLY 6, VEERING > SOUTHWEST 5 TO 7 LATER. SLIGHT OR MODERATE. SHOWERS, THEN RAIN. MODERATE OR > GOOD. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 943AA3A67FD for ; Thu, 19 Aug 2010 10:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.292 X-Spam-Level: X-Spam-Status: No, score=-5.292 tagged_above=-999 required=5 tests=[AWL=1.307, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5Qm7q++WQnc for ; Thu, 19 Aug 2010 10:38:44 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) by core3.amsl.com (Postfix) with ESMTP id B9D2A3A696F for ; Thu, 19 Aug 2010 10:38:43 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39593) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Om95B-0002lf-hc (Exim 4.72) (return-path ); Thu, 19 Aug 2010 18:39:17 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Om95B-0004Y0-GU (Exim 4.67) (return-path ); Thu, 19 Aug 2010 18:39:17 +0100 Date: Thu, 19 Aug 2010 18:39:17 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Richard L. Barnes" In-Reply-To: <50A38D0D-8F66-4A8B-836A-9C8A5C0F9280@bbn.com> Message-ID: References: <50A38D0D-8F66-4A8B-836A-9C8A5C0F9280@bbn.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Phillip Hallam-Baker , keyassure@ietf.org Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:38:49 -0000 On Thu, 19 Aug 2010, Richard L. Barnes wrote: > > Not true. In TLS connection establishment, the server only presents one > key/cert, but different servers for the same domain can present different > keys/certs. Who buys multiple certificates when they only need one? Tony. -- f.anthony.n.finch http://dotat.at/ CROMARTY FORTH TYNE: SOUTH OR SOUTHEAST, 4 OR 5, OCCASIONALLY 6, VEERING SOUTHWEST 5 TO 7 LATER. SLIGHT OR MODERATE. SHOWERS, THEN RAIN. MODERATE OR GOOD. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D053A69F5 for ; Thu, 19 Aug 2010 10:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.767 X-Spam-Level: X-Spam-Status: No, score=-99.767 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWhFG+6Qyod3 for ; Thu, 19 Aug 2010 10:35:25 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 03AD23A6967 for ; Thu, 19 Aug 2010 10:35:21 -0700 (PDT) Received: from [10.20.30.158] (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 o7JHZeJU080963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 10:35:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <185111DC-53F3-4DB0-A00B-185F30EF3493@bbn.com> References: <185111DC-53F3-4DB0-A00B-185F30EF3493@bbn.com> Date: Thu, 19 Aug 2010 10:35:38 -0700 To: "Richard L. Barnes" , Tony Finch From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:35:27 -0000 At 1:22 PM -0400 8/19/10, Richard L. Barnes wrote: >This seems like a bad path to be headed down. There are lots of identifiers that can be tied to public keys: email addresses, SIP URIs, telephone numbers, childhood nicknames. It would be a mistake to try to smash them all into the DNS. +1. The DNS is good for giving information that is related to domain names, not all the users of the things at the domain names. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D917A3A69F5 for ; Thu, 19 Aug 2010 10:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.247 X-Spam-Level: X-Spam-Status: No, score=-5.247 tagged_above=-999 required=5 tests=[AWL=1.352, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFmEe4oL+VTY for ; Thu, 19 Aug 2010 10:33:57 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) by core3.amsl.com (Postfix) with ESMTP id 687693A69A9 for ; Thu, 19 Aug 2010 10:33:57 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:38341) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Om90Z-0000wx-fR (Exim 4.72) (return-path ); Thu, 19 Aug 2010 18:34:31 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Om90Z-0003wa-QR (Exim 4.67) (return-path ); Thu, 19 Aug 2010 18:34:31 +0100 Date: Thu, 19 Aug 2010 18:34:31 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Richard L. Barnes" In-Reply-To: <185111DC-53F3-4DB0-A00B-185F30EF3493@bbn.com> Message-ID: References: <185111DC-53F3-4DB0-A00B-185F30EF3493@bbn.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:34:00 -0000 On Thu, 19 Aug 2010, Richard L. Barnes wrote: > This seems like a bad path to be headed down. There are lots of identifiers > that can be tied to public keys: email addresses, SIP URIs, telephone numbers, > childhood nicknames. It would be a mistake to try to smash them all into the > DNS. In many cases user keys have a username@domain structure so it would make sense for user keys to be signed by a domain key which can in turn be validated using the DNS. > Authenticating identifiers from other protocols should be the job of those > protocols. That sounds like an argument for leaving TLS as it currently is. > It seems like it would be a big enough win for this group to come > up with a better way of binding keys to domain names. That sounds like an argument for putting user keys in the DNS. Sorry for being argumentative but you need to be clear about where and why you are drawing a line :-) Tony. -- f.anthony.n.finch http://dotat.at/ HEBRIDES: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 6 TO GALE 8 LATER. ROUGH. SHOWERS, RAIN LATER. MODERATE OR GOOD. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98FD93A6980 for ; Thu, 19 Aug 2010 10:30:18 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL9yrcz0rFT3 for ; Thu, 19 Aug 2010 10:30:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id CD6443A6967 for ; Thu, 19 Aug 2010 10:30:12 -0700 (PDT) Received: from [192.1.255.185] (port=52475 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Om8wx-000OIH-9I; Thu, 19 Aug 2010 13:30:47 -0400 Message-Id: <50A38D0D-8F66-4A8B-836A-9C8A5C0F9280@bbn.com> From: "Richard L. Barnes" To: Tony Finch In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 13:30:45 -0400 References: X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org, Phillip Hallam-Baker Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:30:19 -0000 >> As long as we can have multiple keys per service, that is fine. > > I can see that support for multiple key signatures might be > necessary to > deal with key rollover. Are there other reasons? Some names provide multiple A records for different hosts. If these hosts have different private keys, they'll need to publish different public keys. >> What I was objecting to was the idea of a single key for the Web >> Service for www.example.com. That is not going to work. > > That's how TLS currently works. Not true. In TLS connection establishment, the server only presents one key/cert, but different servers for the same domain can present different keys/certs. >> At a high level, what I would like to see here is a mechanism that >> allows an application to generate a key pair and request registration >> in the DNS as part of the install package. > > Dynamic DNS updates ought to be part of the solution, though I don't > know > how to make it easier to manage the trust relationship (i.e. the > nsupdate > keys) between the DNS admin and the app admins. I would say that this sort of provisioning information should be out of the scope of the working group. Standard DNS provisioning techniques apply. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C6D3A6980 for ; Thu, 19 Aug 2010 10:27:48 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2i7x4vsdFhr for ; Thu, 19 Aug 2010 10:27:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 1A1F63A69A2 for ; Thu, 19 Aug 2010 10:27:47 -0700 (PDT) Received: from [192.1.255.185] (port=52454 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Om8ub-000OG2-HP; Thu, 19 Aug 2010 13:28:22 -0400 Message-Id: From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 13:28:19 -0400 References: X-Mailer: Apple Mail (2.936) Cc: Tony Finch , keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:27:48 -0000 > oops, just saw a can of worms here. If we are not careful with our > validation scheme, we will end up in a situation where people can use > the S/MIME cert they were issued (e.g. fred@bigbank.com) to set up a > Web Server (https://bigbank.com/) > > That would be bad. The DNS key validation mechanism is going to have > to specify the protocol it is validated for. That would certainly be bad, but it doesn't necessarily follow that you need to specify a protocol. "fred@bigbank.com" and "bigbank.com" are different identifiers, so if you simply make sure that keys are properly bound to identifiers, then you don't need to say anything about protocols. --Richard > > On Thu, Aug 19, 2010 at 1:08 PM, Tony Finch wrote: >> Paul Wouters wrote: >>> On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote: >>>> >>>> In my view user keys do not belong in the DNS because the DNS is an >>>> infrastructure for locating network services, not network users. >>> >>> I disagree. You are locating an identity. Currently, that is >>> mostly done >>> based on an IP address and port. I'd hope tomorrow that would >>> mostly be >>> done based on a public key or hash. Especially with mobile >>> devices, IP's >>> are very volatile. To locate a service or user, we need the DNS. >> >> Yes. At the moment the PKIs for identifying people are rather >> cumbersome. >> It would be nice to be able to use DNSSEC for verifying S/MIME or PGP >> messages. >> >> Tony. >> -- >> f.anthony.n.finch http://dotat.at/ >> SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE >> OR GOOD. >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >> > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E5F3A6982 for ; Thu, 19 Aug 2010 10:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjLzf7mk6lNE for ; Thu, 19 Aug 2010 10:26:22 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) by core3.amsl.com (Postfix) with ESMTP id BEA0E3A6980 for ; Thu, 19 Aug 2010 10:26:22 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:56507) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Om8tF-0007Fa-dC (Exim 4.72) (return-path ); Thu, 19 Aug 2010 18:26:57 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Om8tF-0002zW-4I (Exim 4.67) (return-path ); Thu, 19 Aug 2010 18:26:57 +0100 Date: Thu, 19 Aug 2010 18:26:57 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: keyassure@ietf.org Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:26:23 -0000 On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote: > As long as we can have multiple keys per service, that is fine. I can see that support for multiple key signatures might be necessary to deal with key rollover. Are there other reasons? > What I was objecting to was the idea of a single key for the Web > Service for www.example.com. That is not going to work. That's how TLS currently works. > At a high level, what I would like to see here is a mechanism that > allows an application to generate a key pair and request registration > in the DNS as part of the install package. Dynamic DNS updates ought to be part of the solution, though I don't know how to make it easier to manage the trust relationship (i.e. the nsupdate keys) between the DNS admin and the app admins. Tony. -- f.anthony.n.finch http://dotat.at/ HEBRIDES: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 6 TO GALE 8 LATER. ROUGH. SHOWERS, RAIN LATER. MODERATE OR GOOD. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD243A6980 for ; Thu, 19 Aug 2010 10:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DAVX1-doSHb for ; Thu, 19 Aug 2010 10:25:03 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 74AFA3A68A7 for ; Thu, 19 Aug 2010 10:25:03 -0700 (PDT) Received: by iwn3 with SMTP id 3so2223619iwn.31 for ; Thu, 19 Aug 2010 10:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fkADvVpKhii4iMq8rCO4n7Qwv0M4qlpEZLJLvgbFzZg=; b=qbSb5RNd4FH96MBMTIKAoA8mYMoIrft5TCnJUwp8yUGsEpbD6IBRE9VtGeyRVSz39R jq1vyuEZjatAdEUgzm4N+yPmTpukdKQAXntB2CLNfPWsSTQ0Sv3aV6AYAOrOyLEEgu6S lPYlkfNUmpzEFKo7CQHV22/JvCpFfkXgalI5c= 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:content-transfer-encoding; b=a4jH7819g3y6urBp4UF7M5/qf8rdgYm8pJ9ETLYq2V2CCkp13l75K6Jf6Uo1SCRmdh fThhvAn3/dpXpcGohveT4TSJk4L5O5infvt0j+o1TjzQnSyx9iXJUMdgcUhZxcFbm1n+ chSULH9jePIis/IYW4vVbe89ODqGKboxnZEQc= MIME-Version: 1.0 Received: by 10.231.168.21 with SMTP id s21mr114169iby.123.1282238737160; Thu, 19 Aug 2010 10:25:37 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 19 Aug 2010 10:25:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Aug 2010 13:25:37 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:25:05 -0000 I agree it would be nice to use DNSSEC in the validation path. But the problem is that the DNS management is typically under control of people responsible for managing machines and not people. We have a spec for putting certs onto a Web server and pulling them via HTT= P. oops, just saw a can of worms here. If we are not careful with our validation scheme, we will end up in a situation where people can use the S/MIME cert they were issued (e.g. fred@bigbank.com) to set up a Web Server (https://bigbank.com/) That would be bad. The DNS key validation mechanism is going to have to specify the protocol it is validated for. On Thu, Aug 19, 2010 at 1:08 PM, Tony Finch wrote: > Paul Wouters wrote: >>On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote: >>> >>> In my view user keys do not belong in the DNS because the DNS is an >>> infrastructure for locating network services, not network users. >> >> I disagree. You are locating an identity. Currently, that is mostly done >> based on an IP address and port. I'd hope tomorrow that would mostly be >> done based on a public key or hash. Especially with mobile devices, IP's >> are very volatile. To locate a service or user, we need the DNS. > > Yes. At the moment the PKIs for identifying people are rather cumbersome. > It would be nice to be able to use DNSSEC for verifying S/MIME or PGP > messages. > > Tony. > -- > f.anthony.n.finch =A0 =A0http://dotat.at/ > SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD= . > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381203A68EA for ; Thu, 19 Aug 2010 10:21:44 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwA7yUQsxEnZ for ; Thu, 19 Aug 2010 10:21:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 22E993A67F1 for ; Thu, 19 Aug 2010 10:21:43 -0700 (PDT) Received: from [192.1.255.185] (port=52418 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Om8oj-000O9F-Jr; Thu, 19 Aug 2010 13:22:18 -0400 Message-Id: <185111DC-53F3-4DB0-A00B-185F30EF3493@bbn.com> From: "Richard L. Barnes" To: Tony Finch In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 13:22:16 -0400 References: X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:21:44 -0000 This seems like a bad path to be headed down. There are lots of identifiers that can be tied to public keys: email addresses, SIP URIs, telephone numbers, childhood nicknames. It would be a mistake to try to smash them all into the DNS. Authenticating identifiers from other protocols should be the job of those protocols. It seems like it would be a big enough win for this group to come up with a better way of binding keys to domain names. --Richard On Aug 19, 2010, at 1:08 PM, Tony Finch wrote: > Paul Wouters wrote: >> On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote: >>> >>> In my view user keys do not belong in the DNS because the DNS is an >>> infrastructure for locating network services, not network users. >> >> I disagree. You are locating an identity. Currently, that is mostly >> done >> based on an IP address and port. I'd hope tomorrow that would >> mostly be >> done based on a public key or hash. Especially with mobile devices, >> IP's >> are very volatile. To locate a service or user, we need the DNS. > > Yes. At the moment the PKIs for identifying people are rather > cumbersome. > It would be nice to be able to use DNSSEC for verifying S/MIME or PGP > messages. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR > GOOD. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273803A697B for ; Thu, 19 Aug 2010 10:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZAO7GKH+DVG for ; Thu, 19 Aug 2010 10:18:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2A0F23A696D for ; Thu, 19 Aug 2010 10:18:23 -0700 (PDT) Received: by iwn3 with SMTP id 3so2219263iwn.31 for ; Thu, 19 Aug 2010 10:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UKQkADfPqQxBZjcZ5cIelAZIgWRx71iIDA8pCLyyjns=; b=owaOJo5hmUGwbpw6v+6FfycrzdlnAX/xK2TW9QUcDNKWuV/y02vLyCUcZ1MFIn1MWn IG7vLfPp91qY8AXo9LsDAZop0BrpNcGg9b5geBNjf0qVhcuFzNjgKbX6F97ZUL24O89c iGgOkrcsB5fgnJ6FmUIR1hwnVrCDqCymzmgXs= 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:content-transfer-encoding; b=DWnBaW9DqwlBVpJEyp3Kv872kNrE1tMLURGzss0ISikiCkhMXDRBTObrYZu0LgFCGv 18oRRZicqWm7t1ejA0o2aHWCuFgVMtqsrOI2NNhtC8oMRZn0p0puqSnQnkUDFAc09Yhc jP3Bv6YQx6gkUcihYBFZzFUWHcZjyRIZMp8yg= MIME-Version: 1.0 Received: by 10.231.167.130 with SMTP id q2mr55148iby.163.1282238337851; Thu, 19 Aug 2010 10:18:57 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 19 Aug 2010 10:18:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Aug 2010 13:18:57 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:18:24 -0000 As long as we can have multiple keys per service, that is fine. What I was objecting to was the idea of a single key for the Web Service for www.example.com. That is not going to work. Nor does it need to as the cert is passed in band in SSL (as could be any new keying material format). So the cert can tell the relying party where to look for the instance specific key. It also means that we can punt on issues like key rollover and such. At a high level, what I would like to see here is a mechanism that allows an application to generate a key pair and request registration in the DNS as part of the install package. On Thu, Aug 19, 2010 at 1:01 PM, Tony Finch wrote: > Phillip Hallam-Baker >> >> We should be encouraging people to use a separate private key for each >> physical host. So we certainly should not be creating specs that make it >> hard to do that. > > I think the ship has already sailed on that one. A large proportion of > deployments have some kind of load balancing router / proxy between the > actual servers and the internet, so the mapping between public service > addresses (whether names or numbers) and hosts is completely virtualized. > Also a physical host will often support many virtual hosts, whether they > are entire OS instances or just lightweight web server vhosts. > > Really the key should be per service, and we should not design protocols > with any idea of a visible or externally meaningful map between services > and hosts. > > Tony. > -- > f.anthony.n.finch =A0 =A0http://dotat.at/ > IRISH SEA: SOUTHEAST, VEERING SOUTH 5 TO 7, OCCASIONALLY GALE 8. MODERATE= OR > ROUGH. RAIN THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5923A68EA for ; Thu, 19 Aug 2010 10:18:19 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oavQSt+-fdlS for ; Thu, 19 Aug 2010 10:18:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id B6A563A67F1 for ; Thu, 19 Aug 2010 10:18:17 -0700 (PDT) Received: from [192.1.255.185] (port=52394 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Om8lP-000O5i-Un; Thu, 19 Aug 2010 13:18:52 -0400 Message-Id: From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 13:18:50 -0400 References: X-Mailer: Apple Mail (2.936) Cc: Tony Finch , keyassure@ietf.org Subject: Re: [keyassure] multi-application certificate RRs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:18:19 -0000 SRV is a good idea, but maybe not exactly what we want here. In a related vein, we've been discussing in the XMPP WG how to authenticate delegations of services (so that an outsourced server can authenticate as itself instead of its customer), and this is approach I'm advocating now: _xmpp-client._tcp.example.com SRV 1 1 1 apps.example.net _xmpp-client._tcp.example.com CERT 1 1 1 http://example.com/xmpp.cer (Should have the draft out later this week.) Note, however, that this is a slightly different use case from what we're discussing here. Namely, the goal of the XMPP stuff is to enable some sort of authentication on the SRV in the absence of DNSSEC. It helps the RP figure out what *name* to expect, not what key. If you're assuming DNSSEC and want to bind a key to a name, you don't need to attach the CRYPTO/CERT/whatever RR to the SRV. Since the SRV is DNSSEC-signed, the target host just needs to authenticate as itself, so you would want the key to go with the target hostname (or its A/AAAA record). --Richard On Aug 19, 2010, at 12:50 PM, Phillip Hallam-Baker wrote: > I would hope that if we get people to start using DNS for their keying > material that there would also be more widespread use of SRV. In > particular for Web Services applications since we are likely to end up > with several hundred thousand of those in the not too different > future. > > So if we are going to have > > _http._tcp.example.com SRV 1 1 1 www1.example.com > > Wouldn't it make sense to use the exact same approach for the protocol > specific keying information? > > _http._tcp.example.com SRV 1 1 1 www1.example.com > _http._tcp.example.com CRYPTO "blah .... blah" > > > Note that in the case of SSL the client receives the server cert > during the protocol negotiation. Thus the question is not 'what cert > should I use', it is the same question as in DKIM 'is this key > (certificate) valid'. And if we are using certs we can stick an > extension in the cert to give the prefix at which to find it. > > In DKIM there are actually two separate records. There are key records > that state that a key is valid for the domain and there are policy > records that state that a message from a domain should have a > signature. > > If we are going to provide decent application security we need the > same scheme here. So the protocol specific record is going to be the > policy record and the key record is going to be another record: > > _http._tcp.example.com SRV 1 1 1 www1.example.com > _http._tcp.example.com OPTIONS "ALWAY USE SLL FOR THIS" > _2wefih223h2.example.com CERTHASH "digest=SHA1:wehwefkjhwkjfh" > > > Question: should we copy from DKIM as Stephen suggests or try to > create a fixed binary format label? > > My experience doing DKIM is that we are not going to enumerate all the > possible requirements for the policy record first time and we probably > won't get the certhash record right first time either. > > My preference is to follow the DKIM precedent but use new RRs (not > TXT) as we are assuming people are doing DNSSEC here. > > On Thu, Aug 19, 2010 at 12:35 PM, Tony Finch wrote: >> Paul Wouters wrote: >>> >>> 2) Try to make a new DNS record that can be used by more then just >>> one >>> application (eg not SSHFP) to avoid spamming the apex. >> >> Isn't this contrary to RFC 5507? >> >> Tony. >> -- >> f.anthony.n.finch http://dotat.at/ >> SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. SHOWERS AT >> FIRST. MODERATE >> OR GOOD. >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >> > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F253A6982 for ; Thu, 19 Aug 2010 10:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9a298ETDY4g for ; Thu, 19 Aug 2010 10:12:15 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 84E8A3A69C5 for ; Thu, 19 Aug 2010 10:12:14 -0700 (PDT) Received: by yxk8 with SMTP id 8so945359yxk.31 for ; Thu, 19 Aug 2010 10:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=XaNbeJfTeaHtVVmyLs7aJyCTMUFupEpu6IwgBH5zRF4=; b=lDRJaZDJCdkuKnZsPviQrsqfFLbiSKQy4wUuzKgbP5fMOACFY5QNFHJG4/G0tF1DbT XJGWv9YkZRTyJYM+oaLQY/DcSTzA2md08oejO1uqyJRFyYwNahWPF8E7JkK4oJxDDP7d KO96PYvF+q7DB77vZvN5AtT3qSgbUeOssKb5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hGibjJdFXbCJ4e+hmh0UAmKOa4a6LmZooQTX82FiMR91eHA4pkabAWN7ApN3Pd7xXJ F9aDgTgtkG3lxm15BQResj6A6PBP0GwarkwZu85BdFR3Td5pT7LwZTyMeUYTzWZCow18 6C51aImD8u8qHTaok6ZsQei7a4pgXlW/m06UU= MIME-Version: 1.0 Received: by 10.151.153.1 with SMTP id f1mr585379ybo.153.1282237969213; Thu, 19 Aug 2010 10:12:49 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 19 Aug 2010 10:12:49 -0700 (PDT) Date: Thu, 19 Aug 2010 13:12:49 -0400 Message-ID: From: Phillip Hallam-Baker To: keyassure@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [keyassure] Alternative Charter Proposal X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:12:17 -0000 In response to Paul's request, I propose the following as a better statement of what the group is trying to do and to not do. Objective: Specify mechanisms that allow Internet applications to establish cryptographically enhanced communications through use of information distributed through the DNS. Problem Statement: Today the Internet is insecure by default and security is the exception. If the security of the Internet is to be improved, security must become the default. In particular modern computers have the ability to employ cryptographic security enhancements with minimal or negligible impact on performance, yet only a tiny proportion of Internet traffic is encrypted or authenticated. One of the key weaknesses of the current Internet Public Key Infrastructure (PKI) is that the most widely used Internet PKI is based on the X.500 Directory scheme intended to support an entirely different networking infrastructure. The naming infrastructure of the Internet is the DNS, not X.500. While the PKIX specifications provide a means of mapping X.509v3 attributes to DNS names there is currently no widely accepted, generalized means of achieving the mapping from DNS names to X.509 certificates in particular or to cryptographic keying material in general. DKIM and SSH have demonstrated the utility of this approach in specific domains, these specifications Recent progress in deployment of DNSSEC has renewed focus on the use of the DNS naming system to support cryptographic operations. In particular: * Discovery of keying material by DNS name * Discovery of security criteria by DNS names * Verification of keying material through DNSSEC trust chains Scope: * Use of existing security protocols with DNS established keys * Use of DNS to verify existing certificate / keysigning / security assertion material formats * Means of verifying key/certificate chains using DNSSEC exclusively * Means of verifying key/certificate chains using DNSSEC in combination with other existing means Out-Of-Scope: * Reason for choice of specific trust paths * New formats for keying material (other than raw keys) * New trust architectures (unless they can be expressed in existing formats What I am proposing here is that instead of committing up front to a view of DNSSEC as being intrinsically opposed to existing PKI schemes in that charter, we look for way that we can use DNSSEC and existing infrastructures together. The biggest mistake made in the PKI world was when the PGP and PEM people decided that they could not possibly work together and so they developed to schemes for email security that have competed for mindshare ever since. Jon Callas and I tried to work out ways of overcoming the consequences of that choice on many occasions without much success. The result has been that neither PGP nor SMIME is widely used. -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787233A695D for ; Thu, 19 Aug 2010 10:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.147 X-Spam-Level: X-Spam-Status: No, score=-5.147 tagged_above=-999 required=5 tests=[AWL=1.452, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGKEOmFoiy7D for ; Thu, 19 Aug 2010 10:08:24 -0700 (PDT) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) by core3.amsl.com (Postfix) with ESMTP id 524D63A693D for ; Thu, 19 Aug 2010 10:08:24 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44173) by ppsw-31.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Om8bq-0007cW-KR (Exim 4.72) for keyassure@ietf.org (return-path ); Thu, 19 Aug 2010 18:08:58 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Om8bq-0000lT-7j (Exim 4.67) for keyassure@ietf.org (return-path ); Thu, 19 Aug 2010 18:08:58 +0100 Date: Thu, 19 Aug 2010 18:08:58 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: keyassure@ietf.org Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [keyassure] user keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:08:25 -0000 Paul Wouters wrote: >On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote: >> >> In my view user keys do not belong in the DNS because the DNS is an >> infrastructure for locating network services, not network users. > > I disagree. You are locating an identity. Currently, that is mostly done > based on an IP address and port. I'd hope tomorrow that would mostly be > done based on a public key or hash. Especially with mobile devices, IP's > are very volatile. To locate a service or user, we need the DNS. Yes. At the moment the PKIs for identifying people are rather cumbersome. It would be nice to be able to use DNSSEC for verifying S/MIME or PGP messages. Tony. -- f.anthony.n.finch http://dotat.at/ SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215E43A693D for ; Thu, 19 Aug 2010 10:05:16 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-iUK8h+1xf6 for ; Thu, 19 Aug 2010 10:05:15 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id E90E03A68CB for ; Thu, 19 Aug 2010 10:05:14 -0700 (PDT) Received: by pvg7 with SMTP id 7so943096pvg.31 for ; Thu, 19 Aug 2010 10:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Qyo+zZPStO5mrEqjPc3dSLhOcFqqwUgJ71knmDI4J4M=; b=ZhYvQuGaIMJQ0ir2AsTyaYhjPOZ32sXf6/o0f8JwQcEsf70VS6qchyw/MO7CXEAXMZ OsvHbnDhUFkk8faBMpDPXHjAK8yX8M29C2M41hIOLxksGGFl7vHLV9IapfjiJo2XHfg0 GD5/Z5Z0/W8To3yNGAK+mZST7911e4r3a9Vw8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=PH4QtvwerGDIkqNBZ1AOkS+rllj7DkhIbPIoZAyeiortLTYP1eY06bJA9zBVScAGBQ FsTbpXUcCZqaRpnJoaVWoLqKSjyDXB1NvShi9cP0uYKPxCAed42ZD+Y5glpAvBXW4sC7 IbsVFm7KIyC9dElB88bQvUUtdm+A7bJIy83V4= Received: by 10.142.103.14 with SMTP id a14mr9372wfc.245.1282237549074; Thu, 19 Aug 2010 10:05:49 -0700 (PDT) Received: from [192.168.0.188] ([32.177.170.19]) by mx.google.com with ESMTPS id y16sm1991921wff.2.2010.08.19.10.05.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 10:05:46 -0700 (PDT) Sender: Nicholas Weaver Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Thu, 19 Aug 2010 10:05:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C80DCF9-46B6-4714-83F5-1DE5243B93E2@icsi.berkeley.edu> References: To: Tony Finch X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:05:16 -0000 On Aug 19, 2010, at 10:01 AM, Tony Finch wrote: > Phillip Hallam-Baker >>=20 >> We should be encouraging people to use a separate private key for = each >> physical host. So we certainly should not be creating specs that make = it >> hard to do that. >=20 > I think the ship has already sailed on that one. A large proportion of > deployments have some kind of load balancing router / proxy between = the > actual servers and the internet, so the mapping between public service > addresses (whether names or numbers) and hosts is completely = virtualized. > Also a physical host will often support many virtual hosts, whether = they > are entire OS instances or just lightweight web server vhosts. >=20 > Really the key should be per service, and we should not design = protocols > with any idea of a visible or externally meaningful map between = services > and hosts. However, service should be identified by both hostname AND IP address = depending on the server's preference, thus any scheme that says _keymaterial_.host.mydomain.com as a query should also include a query = for _keymaterial_.{A/AAAA record for host.mydomain.com}, IFF the reference = for _keymaterial_.host.mydomain.com says that IP should be referred OR = the service was contacted based on IP rather than hostname. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BFBB3A6A73 for ; Thu, 19 Aug 2010 10:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.091 X-Spam-Level: X-Spam-Status: No, score=-5.091 tagged_above=-999 required=5 tests=[AWL=1.508, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xje3kwwEH7N for ; Thu, 19 Aug 2010 10:01:05 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) by core3.amsl.com (Postfix) with ESMTP id AC52D3A6A79 for ; Thu, 19 Aug 2010 10:01:03 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:36593) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Om8Uj-0008HG-g8 (Exim 4.72) for keyassure@ietf.org (return-path ); Thu, 19 Aug 2010 18:01:37 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Om8Uj-0008CL-1f (Exim 4.67) for keyassure@ietf.org (return-path ); Thu, 19 Aug 2010 18:01:37 +0100 Date: Thu, 19 Aug 2010 18:01:37 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: keyassure@ietf.org Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:01:06 -0000 Phillip Hallam-Baker > > We should be encouraging people to use a separate private key for each > physical host. So we certainly should not be creating specs that make it > hard to do that. I think the ship has already sailed on that one. A large proportion of deployments have some kind of load balancing router / proxy between the actual servers and the internet, so the mapping between public service addresses (whether names or numbers) and hosts is completely virtualized. Also a physical host will often support many virtual hosts, whether they are entire OS instances or just lightweight web server vhosts. Really the key should be per service, and we should not design protocols with any idea of a visible or externally meaningful map between services and hosts. Tony. -- f.anthony.n.finch http://dotat.at/ IRISH SEA: SOUTHEAST, VEERING SOUTH 5 TO 7, OCCASIONALLY GALE 8. MODERATE OR ROUGH. RAIN THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1223B3A6915 for ; Thu, 19 Aug 2010 09:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+FEojbDqBW1 for ; Thu, 19 Aug 2010 09:50:16 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 9C8E33A6980 for ; Thu, 19 Aug 2010 09:50:16 -0700 (PDT) Received: by ywi4 with SMTP id 4so785263ywi.31 for ; Thu, 19 Aug 2010 09:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rdZG3cNsmnlrkf57f2ldg+lCHSPplx15J13KYdeENzY=; b=UIz9rTW7T5dSw52g/N//3s0gIrdf4g4idvHVu2Y7bdQJBgcQUjOhlQJwCFpKChYTIb ZxML2DfvAnKadEgrQiHsrtqU5+lZwqgYAhujoezkfoik8fHx8IYpEs7Guvi44VMg63Qh OrfAYAsEFpXpl1wCJcWCn/ip2TvMfzpiQ2CQc= 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:content-transfer-encoding; b=OJbczgOat6CYsz7KFcLP/fF4qa+Py9AMRrQjMy5QIwu60vM2e1PCcHzgTKbNF8Otl4 W/92pnLvG5B97TrpyO+LA+4P7p/0BqPT0xPgV1ikBs6tsACzuXdLKYrq18T9e3AoLDwg hi3QVwbhvTbVnmdfl8AmsN2i06hmUq7MMiNSI= MIME-Version: 1.0 Received: by 10.100.134.1 with SMTP id h1mr131207and.105.1282236650777; Thu, 19 Aug 2010 09:50:50 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 19 Aug 2010 09:50:50 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Aug 2010 12:50:50 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] multi-application certificate RRs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:50:18 -0000 I would hope that if we get people to start using DNS for their keying material that there would also be more widespread use of SRV. In particular for Web Services applications since we are likely to end up with several hundred thousand of those in the not too different future. So if we are going to have _http._tcp.example.com SRV 1 1 1 www1.example.com Wouldn't it make sense to use the exact same approach for the protocol specific keying information? _http._tcp.example.com SRV 1 1 1 www1.example.com _http._tcp.example.com CRYPTO "blah .... blah" Note that in the case of SSL the client receives the server cert during the protocol negotiation. Thus the question is not 'what cert should I use', it is the same question as in DKIM 'is this key (certificate) valid'. And if we are using certs we can stick an extension in the cert to give the prefix at which to find it. In DKIM there are actually two separate records. There are key records that state that a key is valid for the domain and there are policy records that state that a message from a domain should have a signature. If we are going to provide decent application security we need the same scheme here. So the protocol specific record is going to be the policy record and the key record is going to be another record: _http._tcp.example.com SRV 1 1 1 www1.example.com _http._tcp.example.com OPTIONS "ALWAY USE SLL FOR THIS" _2wefih223h2.example.com CERTHASH "digest=3DSHA1:wehwefkjhwkjfh" Question: should we copy from DKIM as Stephen suggests or try to create a fixed binary format label? My experience doing DKIM is that we are not going to enumerate all the possible requirements for the policy record first time and we probably won't get the certhash record right first time either. My preference is to follow the DKIM precedent but use new RRs (not TXT) as we are assuming people are doing DNSSEC here. On Thu, Aug 19, 2010 at 12:35 PM, Tony Finch wrote: > Paul Wouters wrote: >> >> 2) Try to make a new DNS record that can be used by more then just one >> =A0 =A0application (eg not SSHFP) to avoid spamming the apex. > > Isn't this contrary to RFC 5507? > > Tony. > -- > f.anthony.n.finch =A0 =A0http://dotat.at/ > SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. SHOWERS AT FIRST. MODE= RATE > OR GOOD. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932B93A695D for ; Thu, 19 Aug 2010 09:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4CH4QBB-Cml for ; Thu, 19 Aug 2010 09:39:45 -0700 (PDT) Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id 724A13A6947 for ; Thu, 19 Aug 2010 09:39:45 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7JGeJb1018360 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 19 Aug 2010 12:40:19 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7JGeJ5F009089 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Aug 2010 12:40:19 -0400 (EDT) Message-Id: From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 12:40:18 -0400 References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> <25610D95-3C55-4920-B33B-B420E8CF639B@gmail.com> X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6078 signatures=637975 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008190118 Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:39:46 -0000 David said basically what I was going to say on your other points, but I wanted to also note the following: On Aug 19, 2010, at 9:01 AM, Phillip Hallam-Baker wrote: > The point you are still not getting here is that the security of the > system is measured from the point of view of the relying party. The > relying party does not choose either the CA or the Registrar, but an > attacker can. Let's describe the assurances that the relying party has in each case: Standard CA DV cert: One of thousands of entities with cert-issuing authority said that the holder of the corresponding private key controls the zone for the domain in question. There may be other people out there who also have certificates that assert that they control the domain, but neither you nor this issuing CA necessarily know if they exist. Every root CA has equivalent authority as far as you're concerned, and an attacker can choose the lowest common denominator CA and serve you those certs at will. DNSSEC domain-key assertion: The person who controls the zone for the domain in question holds the corresponding private key. The only opportunity for mischief or mistake is in the one single path that the zone controller chose: their nameserver (especially if they are doing online signing), the registrar, the registry, and the root (and if there are DS records for sub-domains, whoever controls those). What's more, any substitution of a baddie's DS record for the true domain owner's DS record would be highly visible and likely to be immediately corrected. DNSSEC domain-key assertion plus EV: Not only is there a high level of assurance that you are talking to the person who controls the zone, a third-party has verified who that person is. You can have a substantial degree of trust in that third- party because they have been approved according to the more stringent EV requirements. DNSSEC domain-key assertions are backed up by the technical architecture. CA assertions are backed up by standards groups, reputation, and perhaps even legal liability. The caveat for both systems are that technical vulnerabilities can and do happen, but I think that's well beyond this group's mandate to discuss. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07E03A6915 for ; Thu, 19 Aug 2010 09:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.031 X-Spam-Level: X-Spam-Status: No, score=-5.031 tagged_above=-999 required=5 tests=[AWL=1.568, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmYNydn5ItTl for ; Thu, 19 Aug 2010 09:35:21 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) by core3.amsl.com (Postfix) with ESMTP id D2C9A3A693D for ; Thu, 19 Aug 2010 09:35:20 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:38633) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Om85r-0005zd-da (Exim 4.72) for keyassure@ietf.org (return-path ); Thu, 19 Aug 2010 17:35:55 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Om85r-0004v1-7n (Exim 4.67) for keyassure@ietf.org (return-path ); Thu, 19 Aug 2010 17:35:55 +0100 Date: Thu, 19 Aug 2010 17:35:55 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: keyassure@ietf.org Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [keyassure] multi-application certificate RRs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:35:23 -0000 Paul Wouters wrote: > > 2) Try to make a new DNS record that can be used by more then just one > application (eg not SSHFP) to avoid spamming the apex. Isn't this contrary to RFC 5507? Tony. -- f.anthony.n.finch http://dotat.at/ SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. SHOWERS AT FIRST. MODERATE OR GOOD. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52BC23A6951 for ; Thu, 19 Aug 2010 08:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKmM9vpem5Z8 for ; Thu, 19 Aug 2010 08:30:41 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id B77E53A699E for ; Thu, 19 Aug 2010 08:30:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 5A9F2DC4D7A; Thu, 19 Aug 2010 08:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAJdq-kv5Syf; Thu, 19 Aug 2010 08:31:07 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 262C3DC4D6C; Thu, 19 Aug 2010 08:31:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Thu, 19 Aug 2010 08:31:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <033377D8-18A6-475F-A520-8E71F59CA921@virtualized.org> References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> <25610D95-3C55-4920-B33B-B420E8CF639B@gmail.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 15:30:48 -0000 On Aug 19, 2010, at 6:01 AM, Phillip Hallam-Baker wrote: > The registrar does the work but the registrar does not even have a = key. It's the registry that has the key.=20 The registrar does essentially nothing. I remain a bit confused as to = why you keep harping on the registrar here. The registrar accepts = public information from the registrant and asks the registry to place = that information into the registry's zone. If the registrar accidentally = or intentionally asks for the wrong information to be placed into the = zone, the registrant will notice as soon as the registry publishes the = zone.=20 Exactly what threat do you see the registrar facilitating? > The simple solution for this is to allow for certs in the dnssec trust = path to validate KSKs. This would supplement the TLD signature if = available. This allows the liability issues to be managed, moots the = limitations of a single root of trust and allows for certain practical = efficiency optimizations. Pointer to your draft? > We can then use dnssec for anything from opportunistic encryption all = the way up to million dollar commercial transactions.=20 We can do this today. Regards, -drc Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8265D3A68D2 for ; Thu, 19 Aug 2010 08:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.77 X-Spam-Level: X-Spam-Status: No, score=-99.77 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qALvephTtxp for ; Thu, 19 Aug 2010 08:14:04 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2E61F3A689B for ; Thu, 19 Aug 2010 08:14:04 -0700 (PDT) Received: from [10.20.30.158] (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 o7JFEaQn070988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 08:14:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> Date: Thu, 19 Aug 2010 08:14:34 -0700 To: Phillip Hallam-Baker From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "keyassure@ietf.org" Subject: [keyassure] Charter discussion: please send alternate text X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 15:14:07 -0000 If you feel that the proposed charter text is using the wrong model, please send specific proposals to the list so that others can consider them. Slowly expanding on your model description over the course of many messages doesn't seem to be working at gaining consensus. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019BD3A694E for ; Thu, 19 Aug 2010 07:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiTr8oMiW3rT for ; Thu, 19 Aug 2010 07:59:16 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id DE7573A6951 for ; Thu, 19 Aug 2010 07:59:15 -0700 (PDT) Received: by qyk1 with SMTP id 1so3170179qyk.10 for ; Thu, 19 Aug 2010 07:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=cShXYZPMs90fPqAH8ePpgKNAVy/XXxRpOxoYVxQP8io=; b=ksHDfxXuUBhRF4CFgUPoMNV3bdWygZOZ3roHYsQbobFRG1uaTmZxeudnWaLlRvxgU1 juvC4E8xjJPDj1vRiC1fQTAr71UCMptC1GyPNuVZeaDmjvUPkOZKoFid8WqWkxpiutOo y6wlphgEcarTIS1k4j7DDBvYr3TdcS7Vnnihs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=BxGPqRaDh/D6jRtmYuO+r1n3n9U4TsPDrPrUaamKvmCXq8jWW3ySAbL+bCflU48z0J znoB84PCoQW1E7aYfz9U3cgeXwthkv/r7K2BTCnJ4z628GWpRIWDeo5AcJBULz+yeQ1T 1idpbO2Q7C1scRu8fdhpr4RR3V3dCI7zDh7EE= Received: by 10.224.11.140 with SMTP id t12mr6535305qat.314.1282229990345; Thu, 19 Aug 2010 07:59:50 -0700 (PDT) Received: from [10.0.1.8] (c-98-216-39-121.hsd1.ma.comcast.net [98.216.39.121]) by mx.google.com with ESMTPS id l8sm1797102qck.42.2010.08.19.07.59.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 07:59:48 -0700 (PDT) References: <4C6B90C5.8080503@nic.cz> <4C6C7718.40003@cs.tcd.ie> Message-Id: From: Phillip Hallam-Baker To: Stephen Farrell In-Reply-To: <4C6C7718.40003@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Thu, 19 Aug 2010 10:59:47 -0400 Cc: "keyassure@ietf.org" , Paul Hoffman Subject: [keyassure] DKIM Format X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 14:59:17 -0000 I took another look at DKIM. We do have a few differences. One of the = most important being that we are pretty much assuming DNSSEC capable = clients and infrastructures. So we are looking at at least one new RR = and I think we need three if we are going to do a complete job. The big question at this point in my view is whether the format is DKIM = style unrestricted text field with a registry of tags or a DNS style = byte code field approach with fixed fields. I don't much care about the bit packing issue but I definitely want = extensibility. This is not a massively difficult problem but we may make it one if we = have a fixed format record as NXT was. I don't want to have to create a = new RR for each iteration of the design. I want an extensible record = format. Whether people agree with me or not on the need for my approach, I hope = we can agree that pki has proved to be deceptively complex in the past. = I can't see that we lose anything from an extensible format. Coming to = consensus on a fixed format is going to be impossible. My experience in this field suggests that it is going to be highly = desirable to have a lot of experimentation with different approaches and = converge on the ones that work. What works for mail may not work for web = may not work for web services. =20 Sent from my iPad On Aug 18, 2010, at 8:13 PM, Stephen Farrell = wrote: >=20 > Quick question: did you consider DKIM key records for this? > (With a new "s=3D" value in the TXT RR.) >=20 > If so, why don't they rate a mention? If not, maybe worth a > look? >=20 > S. >=20 > On 18/08/10 15:45, Paul Hoffman wrote: >> Greetings again. A gang of us created a draft that pulls together = some of the many ideas that have been floating around. There are = multiple options for some features, so we chose one option in each = category and started an appendix to document the choices. >>=20 >> >>=20 >> Discussion is welcome. Please don't assume that any of the options = are set in stone, although note that changing some options might also = require changing other options at the same time. In particular, I think = my idea of listing ports is going to go away, given that few sites run = services on different ports but keep the same domain name. >>=20 >> --Paul Hoffman, Director >> --VPN Consortium >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >>=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448DF3A6878 for ; Thu, 19 Aug 2010 07:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.774 X-Spam-Level: X-Spam-Status: No, score=-99.774 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjhUcM1xFWov for ; Thu, 19 Aug 2010 07:59:04 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 83D3C3A6829 for ; Thu, 19 Aug 2010 07:59:04 -0700 (PDT) Received: from [10.20.30.158] (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 o7JExYwM069979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 07:59:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 19 Aug 2010 07:59:28 -0700 To: Stephen Farrell From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] Key linkage draft, -00 edition X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 14:59:05 -0000 >Quick question: did you consider DKIM key records for this? >(With a new "s=" value in the TXT RR.) > >If so, why don't they rate a mention? If not, maybe worth a >look? First off, the idea of TXT RRs without _label prefixes has been mostly deprecated in the IETF. Second, the idea of saying "this isn't DKIM, it's this new thing" by changing "s=" is begging for trouble. There are enough tricky semantics in the DKIM spec (not as many as in PKIX, but it sometimes feels that way) that reusing it would likely prevent us from having the freedom we want. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F933A6967 for ; Thu, 19 Aug 2010 06:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNr4w5PkC1WH for ; Thu, 19 Aug 2010 06:07:26 -0700 (PDT) Received: from hacklheber.piermont.com (hacklheber.piermont.com [166.84.7.14]) by core3.amsl.com (Postfix) with ESMTP id 3D6253A694D for ; Thu, 19 Aug 2010 06:07:26 -0700 (PDT) Received: from bellman.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 2867A28CFC5; Thu, 19 Aug 2010 09:07:55 -0400 (EDT) Received: from jabberwock.cb.piermont.com (jabberwock.cb.piermont.com [10.160.2.107]) by bellman.cb.piermont.com (Postfix) with ESMTP id F040F2DE32F; Thu, 19 Aug 2010 09:07:54 -0400 (EDT) Date: Thu, 19 Aug 2010 09:07:54 -0400 From: "Perry E. Metzger" To: Phillip Hallam-Baker Message-ID: <20100819090754.1746ff92@jabberwock.cb.piermont.com> In-Reply-To: <4BD940B1-8A5E-4E0C-99A8-97945CF8873B@gmail.com> References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <20100818225922.5b876717@teensy> <4BD940B1-8A5E-4E0C-99A8-97945CF8873B@gmail.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-apple-darwin10.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 13:07:27 -0000 On Thu, 19 Aug 2010 01:10:39 -0400 Phillip Hallam-Baker wrote: > We have a proposed charter that asserts that the benefit of dnssec > lies in having a single root of trust because that means fewer Leave people alone to get their work done. You're not going to convince them, you're just going to annoy them, and the mere existence of a standard doesn't imply that anything will actually be deployed (or do you use RSVP every day? or how about CLNP?) > Don't forget that in the originally proposed and deployed ssl model > that there was a single root of trust. I don't think that was ever the case. Netscape invented it, and the first browsers they shipped with SSL had multiple roots. Anyway, if you don't like the work, stay away. Leave the people who want to try it alone. Perry -- Perry E. Metzger perry@piermont.com Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7A03A6948 for ; Thu, 19 Aug 2010 06:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDG0hiiHdYQV for ; Thu, 19 Aug 2010 06:01:09 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 8B2FE3A689B for ; Thu, 19 Aug 2010 06:01:09 -0700 (PDT) Received: by qwc9 with SMTP id 9so1832168qwc.31 for ; Thu, 19 Aug 2010 06:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=kAhZf6U4HSkDnhoQNKHev1D3IN3jLDAzaesMI6h8hkA=; b=IfJd9vQddI+So48U2g75xrXyzDmb5qtVsvTS4mLPfLe+X798geUbbX7sJdJ6qxkT5/ BDugg4I01u8mD74qHzMkk/C/T4cdxBxV2dulcWTzQHwQWxcmkcSzHsejI8CCvjd9ote5 1RjgJ0R4MUMfa44zlSCWyPD92fwNleWp77uUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=J8NaWYt1WbaCwuxUiGqiNGDgtwmKu3rUWLSO5qlo1UQhJbp8KaedHACIKeuibM06LO n+JYGBuLir26gu8NivX27MfTOLY2gWmivm6+aDdER3TN/ch7lOfrbverAWX7HXkQbaiW FwJm6T5K0Ab9dTk2AS3axMK2yAnFFIEusX51o= Received: by 10.224.112.73 with SMTP id v9mr6427055qap.327.1282222903643; Thu, 19 Aug 2010 06:01:43 -0700 (PDT) Received: from [10.0.1.8] (c-98-216-39-121.hsd1.ma.comcast.net [98.216.39.121]) by mx.google.com with ESMTPS id r38sm1678883qcs.2.2010.08.19.06.01.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 06:01:42 -0700 (PDT) References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> <25610D95-3C55-4920-B33B-B420E8CF639B@gmail.com> Message-Id: From: Phillip Hallam-Baker To: Steve Schultze In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-3--1026977615 Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Thu, 19 Aug 2010 09:01:39 -0400 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 13:01:15 -0000 --Apple-Mail-3--1026977615 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The reason I think we can do better is that we can block downgrade = attack. Validating domain names is not the issue because I bank with a = company, not a domain name. At the moment the biggest holes in smime and ssl are * there is no way to know if the web site uses ssl * there is no way to know if the recipient can accept smime * there is no way to find an smime recipient cert that is widely = supported All of these stem from the fact that x.509 certs are not properly = integrated into dns. And those are the areas where I see big potential = for creating a unique value for dnssec. There are several million ssl cert owners already using crypto. They are = the potential early adopter market.=20 The point you are still not getting here is that the security of the = system is measured from the point of view of the relying party. The = relying party does not choose either the CA or the Registrar, but an = attacker can.=20 At present I can't even know who the validator in a dnssec chain is. The = registrar does the work but the registrar does not even have a key. It's = the registry that has the key. Dnssec architecture predates the = registrar / registry split in .com. The simple solution for this is to allow for certs in the dnssec trust = path to validate KSKs. This would supplement the TLD signature if = available. This allows the liability issues to be managed, moots the = limitations of a single root of trust and allows for certain practical = efficiency optimizations. We can then use dnssec for anything from = opportunistic encryption all the way up to million dollar commercial = transactions.=20 Sent from my iPad On Aug 19, 2010, at 2:05 AM, Steve Schultze wrote: >=20 > On Aug 19, 2010, at 1:33 AM, Phillip Hallam-Baker wrote: >> But my security is affected by the place that mybank.com registers = myemployer.com registers and so on. >=20 > mybank.com will gravitate toward more trustworthy registrars (because = exclusivity promises actual increased security), rather than the = cheapest option (which is what the current DV CA model encourages). >=20 >> If the ui does not tell the relying party who signed then the = security of the system for the relying party is the security of the = least diligent signer. >=20 > That is not true. The security of the system for the relying party is = the security of the signer that the domain owner chooses, and in a = market in which the cost differential is negligible (the likely market) = this will optimize for security of both parties (domain owner and = relying party). >=20 >> As far as the registrar issue is concerned, There is a lot of = complexity there. What the customer thinks is a registrar may be a = reseller using an outsourced dns publisher. So that is three parties not = one.=20 >=20 > Agreed, but the exclusive and public nature of DNS registration makes = this much less significant. >=20 >> First possible line of attack is a Twitter style password reset = request. >=20 > I'm not sure I understand what the attack vector is here in the DNS = model. In any event, it's far better security than thousands of trusted = (and often undisclosed) CAs/SubCAs/RAs. >=20 >> Second is to claim a zone transfer. >=20 > If bankofamerica.com isn't worried about this today on a basic = name-to-IP level, I think we have solved it to a significant degree. >=20 >> Then there are typo attacks=20 >=20 > Agreed. Totally unsolvable on the DNSSEC layer and a great example of = where CAs are still of critical importance in the domain-to-legal-entity = chain. >=20 >> All entirely justifiable if all you are trying to do is to provide = almost as good security as dv ssl certs. >=20 > No, _better_ than DV SSL certs (when it comes to domain-to-key = mapping). >=20 >> But what I am saying is that there is no reason not to have the = option of almost as good and very much better. >=20 > ] > The "very much better" part is essential, but it relies on the ability = of DNSSEC to ensure a superior domainname-to-owner mapping. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure --Apple-Mail-3--1026977615 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The reason I think we can do better = is that we can block downgrade attack. Validating domain names is not = the issue because I bank with a company, not a domain = name.

At the moment the biggest holes in smime = and ssl are

* there is no way to know if the = web site uses ssl
* there is no way to know if the recipient = can accept smime
* there is no way to find an smime recipient = cert that is widely = supported


All of these stem from = the fact that x.509 certs are not properly integrated into dns. And = those are the areas where I see big potential for creating a unique = value for dnssec.

There are several million ssl = cert owners already using crypto. They are the potential early adopter = market. 


The point you are = still not getting here is that the security of the system is measured = from the point of view of the relying party. The relying party does not = choose either the CA or the Registrar, but an attacker = can. 

At present I can't even know who the = validator in a dnssec chain is. The registrar does the work but the = registrar does not even have a key. It's the registry that has the key. = Dnssec architecture predates the registrar / registry split in = .com.

The simple solution for this is to allow = for certs in the dnssec trust path to validate KSKs. This would = supplement the TLD signature if available. This allows the liability = issues to be managed, moots the limitations of a single root of trust = and allows for certain practical efficiency optimizations. We can then = use dnssec for anything from opportunistic encryption all the way up to = million dollar commercial = transactions. 


Sent from my = iPad

On Aug 19, 2010, at 2:05 AM, Steve Schultze <sjs@Princeton.EDU> = wrote:


On Aug 19, 2010, at 1:33 AM, Phillip = Hallam-Baker wrote:
But my security is affected by = the place that mybank.com registers myemployer.com registers and so = on.

mybank.com will gravitate toward more = trustworthy registrars (because exclusivity promises actual increased = security), rather than the cheapest option (which is what the current DV = CA model encourages).

If the ui does not tell the = relying party who signed then the security of the system for the relying = party is the security of the least diligent = signer.

That is not true. =  The security of the system for the relying party is the security = of the signer that the domain owner chooses, and in a market in which = the cost differential is negligible (the likely market) this will = optimize for security of both parties (domain owner and relying = party).

As far as the registrar issue is = concerned, There is a lot of complexity there. What the customer thinks = is a registrar may be a reseller using an outsourced dns publisher. So = that is three parties not one. 
=
Agreed, but the exclusive and public nature of DNS = registration makes this much less significant.

First possible line of attack is = a Twitter style password reset = request.

I'm not sure I = understand what the attack vector is here in the DNS model.  In any = event, it's far better security than thousands of trusted (and often = undisclosed) CAs/SubCAs/RAs.

Second is to claim a zone = transfer.

If bankofamerica.com isn't = worried about this today on a basic name-to-IP level, I think we have = solved it to a significant degree.

Then there are typo attacks 
=
Agreed.  Totally unsolvable on the DNSSEC layer and = a great example of where CAs are still of critical importance in the = domain-to-legal-entity chain.

All entirely justifiable if all you are trying to do is to = provide almost as good security as dv ssl = certs.

No, _better_ than DV SSL certs = (when it comes to domain-to-key mapping).

But what I am saying is that there is no reason not to = have the option of almost as good and very much = better.
]
The "very much better" part = is essential, but it relies on the ability of DNSSEC to ensure a = superior domainname-to-owner = mapping.
_______________________________________________
keyassure mailing list
keyassure@ietf.org
= https://www.ietf.= org/mailman/listinfo/keyassure
= --Apple-Mail-3--1026977615-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB683A68B8 for ; Thu, 19 Aug 2010 05:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3R8vlwxnkZr7 for ; Thu, 19 Aug 2010 05:33:03 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 5017E3A6903 for ; Thu, 19 Aug 2010 05:32:32 -0700 (PDT) Received: by qwc9 with SMTP id 9so1797939qwc.31 for ; Thu, 19 Aug 2010 05:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=BV5JYDRvIE+Rs6VIwd8cUDN5L32lYeJVrkzINqcJ4eA=; b=RJdS9f42z9jNHGfBcOSWtMzLvsVcwblnt/CNfads5ar30j9XTCeETEgJnEA4Gii6J/ xDRcZgRcuFW01VgIzSzfGzLoFE/3qVOe0gJPxjDp3qEsNHJ5tGNDswqyh6SwB75w6f0/ rWiGVqiq0g/jXyTWtb7HuSh+P1JsJB6RfB96I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=H7AUEaDpws+7Ygw4nBy3vt/7mNpmuJKUxK70FSgGlMe3lY1I1usQkG2Ktk+yrOYt1z 6vPqvI8tVRMYQI5m2hFyI34vsTIZKUcMuRcMi+dtMwjxiECu8eYp7NmE+jM6WhGlE+EV UW+WtkNLIyG+3Q33iPoSDuYJNA5cr2DjBC3B8= Received: by 10.229.221.203 with SMTP id id11mr7137625qcb.222.1282221116300; Thu, 19 Aug 2010 05:31:56 -0700 (PDT) Received: from [10.0.1.8] (c-98-216-39-121.hsd1.ma.comcast.net [98.216.39.121]) by mx.google.com with ESMTPS id e6sm1641451qcr.41.2010.08.19.05.31.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 05:31:54 -0700 (PDT) References: <4C6CDA8D.8070205@nic.cz> Message-Id: <38BEE0F5-37CE-4ABC-8BB4-957766AC2BB1@gmail.com> From: Phillip Hallam-Baker To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4C6CDA8D.8070205@nic.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Thu, 19 Aug 2010 08:31:52 -0400 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 12:33:47 -0000 X-List-Received-Date: Thu, 19 Aug 2010 12:33:47 -0000 Take out all the wording in the current charter entirely. You don't have to say anything about trust models. Not unless you want = to debate the merits of ICANN. You certainly don't have to make claims = that the ICANN root is better than existing ssl schemes.=20 Instead I would simply state that the purpose of the list is to discuss = how to use information in the dns to enable applications to obtain keys. I would then follow up with statements of high level objectives. One of = these being enabling ubiquitous encryption which in turn requires that = there be no additional out of pocket cost per server. I would then add in preventing downgrade attack as a possible objective. Dubious claims of fact have no place in a charter. DKIM demonstrates = that it is quite possible to make useful use of keys in the dns without = dnssec at all. It is also quite possible to make use of keys when only = the local zone is signed without the upper zone signing the KSK.=20 You have to be realistic when designing a security protocol. The only = reason that a security protocol is necessary in the first place is that = people do wrong things and bad things. If you want to propose a security = scheme based on trusting one party to never do the wrong thing and then = declare that one party off limits for examination, expect security = people to be skeptical. Just take out the unfounded claims about single trust roots and we don't = need to discuss the fact that they are unfounded assumptions. Sent from my iPad On Aug 19, 2010, at 3:17 AM, Ond=C5=99ej Sur=C3=BD = wrote: > On 18.8.2010 17:17, Phillip Hallam-Baker wrote: >> I disagree with the statement in the proposed charter >=20 > Then propose alternative wording. Or what to add or what to remove. >=20 >> We have a pki infrastructure that has certain capabilities and = certain >> limitations. We have the expectation of a dnssec infrastructure with >> other capabilities and limitations. >=20 > And there are some capabilities and limitations which are same and = there are some capabilities which are superior in DNSSEC and some which = are superior in PKIX. So what are you trying to say? >=20 > DNSSEC will not be able to provide identity check. But it keeps the = security trust as close to infrastructure as possible. You have to = trust your DNS and keep it secure. >=20 > It was already discussed and my feeling is that the general consensus = is that DV-certs are as at the same or lower level than "DNSSEC-certs". = I propose to not discuss this again, since this is not the purpose of = the mailing list. The purpose is to create solution to be able to = establish secure TLS connection out of DNS data. >=20 >> I am not too interested in just re-doing the features already >> supported in existing pki at lower out of pocket expense >=20 > And there are many people who are interested also in that. >=20 >> I want to make EV certs work well with Dnssec as an option. If 100% = of >> Internet traffic is encrypted, people may start to see the value of >> the service that CAs really provide. >=20 > We had this in mind when we wrote: >=20 > "The DNSSEC root trust anchor can also be used for additional = validation during the current path validations. By validating that the = certificate presented is the certificate identified by the DNS, we can = provide additional confidence that the client is connecting to the = intended server - this helps alleviate concerns that a valid certificate = has been obtained by an attacker (for example from a CA not used by the = victim)." >=20 >> I don't agree with the idea that a single root of trust is desirable >> or provides any advantage whatsoever. It is one of the features we >> need to fix. The Internet is a network of peers, not serfs. The Icann >> scheme has it's uses but it does not have to be the only scheme = people >> are allowed to use. >=20 > There is no single root of trust in the dnssec model. There are as = much trust roots as you configure to validate. DNSSEC signed root just = makes things more easy to implement. >=20 >> As a practical matter we can't escape from x.509 entirely. Ssl is set >> up to use certs. We will do much better to put certs or cert hashes = in >> the dns than raw keys. If we use raw keys we then have to do much = More >> drastic revision to ssl libraries. We have to recode both the client >> and the server rather than just the client. I hate asn1 as much as >> anyone, but it's no real pain to wrap a key as a self signed cert. >>=20 >>=20 >> We should look to make the best system we can, not simply replicate >> what already exists for cheap. >=20 > This is much in contrary with what you said in previous paragraph. = The best system could require as to change not even our thinking, but = also the ssl libraries, clients and servers. Let's not close this = option. >=20 > Ondrej > --=20 > Ond=C5=99ej Sur=C3=BD > vedouc=C3=AD v=C3=BDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B4A3A68E0 for ; Thu, 19 Aug 2010 00:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1u1I4K6Xd6w for ; Thu, 19 Aug 2010 00:17:30 -0700 (PDT) Received: from mail.nic.cz (mh.nic.cz [217.31.204.67]) by core3.amsl.com (Postfix) with ESMTP id 0075A3A6809 for ; Thu, 19 Aug 2010 00:17:29 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 328E073431A for ; Thu, 19 Aug 2010 09:17:34 +0200 (CEST) Message-ID: <4C6CDA8D.8070205@nic.cz> Date: Thu, 19 Aug 2010 09:17:33 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:18:34 -0000 On 18.8.2010 17:17, Phillip Hallam-Baker wrote: > I disagree with the statement in the proposed charter Then propose alternative wording. Or what to add or what to remove. > We have a pki infrastructure that has certain capabilities and certain > limitations. We have the expectation of a dnssec infrastructure with > other capabilities and limitations. And there are some capabilities and limitations which are same and there are some capabilities which are superior in DNSSEC and some which are superior in PKIX. So what are you trying to say? DNSSEC will not be able to provide identity check. But it keeps the security trust as close to infrastructure as possible. You have to trust your DNS and keep it secure. It was already discussed and my feeling is that the general consensus is that DV-certs are as at the same or lower level than "DNSSEC-certs". I propose to not discuss this again, since this is not the purpose of the mailing list. The purpose is to create solution to be able to establish secure TLS connection out of DNS data. > I am not too interested in just re-doing the features already > supported in existing pki at lower out of pocket expense And there are many people who are interested also in that. > I want to make EV certs work well with Dnssec as an option. If 100% of > Internet traffic is encrypted, people may start to see the value of > the service that CAs really provide. We had this in mind when we wrote: "The DNSSEC root trust anchor can also be used for additional validation during the current path validations. By validating that the certificate presented is the certificate identified by the DNS, we can provide additional confidence that the client is connecting to the intended server - this helps alleviate concerns that a valid certificate has been obtained by an attacker (for example from a CA not used by the victim)." > I don't agree with the idea that a single root of trust is desirable > or provides any advantage whatsoever. It is one of the features we > need to fix. The Internet is a network of peers, not serfs. The Icann > scheme has it's uses but it does not have to be the only scheme people > are allowed to use. There is no single root of trust in the dnssec model. There are as much trust roots as you configure to validate. DNSSEC signed root just makes things more easy to implement. > As a practical matter we can't escape from x.509 entirely. Ssl is set > up to use certs. We will do much better to put certs or cert hashes in > the dns than raw keys. If we use raw keys we then have to do much More > drastic revision to ssl libraries. We have to recode both the client > and the server rather than just the client. I hate asn1 as much as > anyone, but it's no real pain to wrap a key as a self signed cert. > > > We should look to make the best system we can, not simply replicate > what already exists for cheap. This is much in contrary with what you said in previous paragraph. The best system could require as to change not even our thinking, but also the ssl libraries, clients and servers. Let's not close this option. Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9C63A689F for ; Thu, 19 Aug 2010 00:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZrXsLCRTieN for ; Thu, 19 Aug 2010 00:04:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id CA2463A689E for ; Thu, 19 Aug 2010 00:04:33 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 3F69473431A for ; Thu, 19 Aug 2010 09:05:08 +0200 (CEST) Message-ID: <4C6CD7A4.8000802@nic.cz> Date: Thu, 19 Aug 2010 09:05:08 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:04:35 -0000 On 19.8.2010 05:38, David Conrad wrote: > [Just joined this list and may not be staying long if this is > typical subject matter] David, I would like you to stay. >> They may be called a non profit but they certainly pay some >> handsome salaries. > > So... keyassure is an yet another ICANN-bashing list? No, it's not. And I'll try to make sure it stays on topic as much I as will be able to do so. > O joy, O rapture. What does the salary ICANN pays have to do with > anything relevant to what I thought this list was going to be > discussing? Please all, keep on topic. Stay out of attacking other people just because your opinion isn't heard. Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5F03A6864 for ; Thu, 19 Aug 2010 00:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.454 X-Spam-Level: X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAV4LNcfCnbq for ; Thu, 19 Aug 2010 00:01:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 074563A67E5 for ; Thu, 19 Aug 2010 00:01:34 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 74F7073431A for ; Thu, 19 Aug 2010 09:02:08 +0200 (CEST) Message-ID: <4C6CD6F0.7090609@nic.cz> Date: Thu, 19 Aug 2010 09:02:08 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <7B873166-52C0-4D25-B9D2-1B3D4C8BC827@princeton.edu> <0935306E-39BB-4001-BBA6-E2EF51C360F8@virtualized.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:01:36 -0000 [moderator hat on] This is entirely outside the topic of this mailing list. Either please explain how is this related to the proposed problem statement or take it elsewhere. This is not a list to discuss ICANN policies. [/moderator hat off] On 19.8.2010 07:39, Phillip Hallam-Baker wrote: > The charging issue is what the domain name owner is expected to pay > to have dnssec once this monopoly provider infrastructure is > deployed. ICANN extracts a rent on every domain name as does VeriSign > in .com. Do we have any guarantee that this rent will not increase in > either case? > > I would have thought that quite obvious but instead you pose > hypotheticals about how much ICANN is going to charge VeriSign, as if > that would be a concern for anyone. > > Sent from my iPad > > On Aug 18, 2010, at 11:51 PM, David Conrad > wrote: > >> On Aug 18, 2010, at 7:51 PM, Steve Schultze wrote: >>>> In the SSL cert case we do have an actual single root, the >>>> WebTrust auditors. >>> No, we have a single standard (well, two... one for EV and >>> another for everything else) which leaves huge areas of ambiguity >>> and latitude for browser/OS vendors to interpret compliance and >>> tremendous holes when it comes to god-like delegation after >>> approval. >> >> And, of course, WebTrust auditors could never be bribed... >> >>> Are they charging anything for signing TLD DS records? >> >> Likely a rhetorical question, but just in case: no, ICANN does not >> charge for accepting DS records (or anything else) from TLDs. >> VeriSign similarly does not charge for accepting authorized root >> zone change requests from ICANN, generating, signing, and >> transmitting the root zone to the root server operators. And, of >> course, the root server operators do not charge for serving the >> root zone on their servers. >> >> Regards, -drc >> >> _______________________________________________ keyassure mailing >> list keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > _______________________________________________ keyassure mailing > list keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612E63A6843 for ; Wed, 18 Aug 2010 23:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5Btv+S7pNO4 for ; Wed, 18 Aug 2010 23:59:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id E25F13A6809 for ; Wed, 18 Aug 2010 23:59:27 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 9573473431A for ; Thu, 19 Aug 2010 09:00:00 +0200 (CEST) Message-ID: <4C6CD670.9010709@nic.cz> Date: Thu, 19 Aug 2010 09:00:00 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <20100818204352.GB94188@shinkuro.com> <9AA3BC53-A3E1-46AC-B890-E1487283D13A@gmail.com> In-Reply-To: <9AA3BC53-A3E1-46AC-B890-E1487283D13A@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 06:59:29 -0000 On 19.8.2010 04:26, Phillip Hallam-Baker wrote: > I want to use dnssec without the ICANN root. You are free to do so. The way how you configure your DNSSEC validating resolver is entirely up to you. And please note that I would like to discuss things like which RR type to use and how to secure the last mile. The "How trustworthy is ICANN" discussion is outside the topic of this mailing list. So please all keep that in mind. Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A2C3A682A for ; Wed, 18 Aug 2010 23:04:52 -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=0.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWHoXsQoUirC for ; Wed, 18 Aug 2010 23:04:51 -0700 (PDT) Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id D10813A67A4 for ; Wed, 18 Aug 2010 23:04:50 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7J65PRJ019849 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 19 Aug 2010 02:05:25 -0400 Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7J65Oh9011999 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Aug 2010 02:05:24 -0400 (EDT) From: Steve Schultze Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-14--1051953627 Date: Thu, 19 Aug 2010 02:05:24 -0400 In-Reply-To: <25610D95-3C55-4920-B33B-B420E8CF639B@gmail.com> To: keyassure@ietf.org References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> <25610D95-3C55-4920-B33B-B420E8CF639B@gmail.com> Message-Id: X-Mailer: Apple Mail (2.1077) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6078 signatures=637975 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008180276 Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 06:04:52 -0000 --Apple-Mail-14--1051953627 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 19, 2010, at 1:33 AM, Phillip Hallam-Baker wrote: > But my security is affected by the place that mybank.com registers = myemployer.com registers and so on. mybank.com will gravitate toward more trustworthy registrars (because = exclusivity promises actual increased security), rather than the = cheapest option (which is what the current DV CA model encourages). > If the ui does not tell the relying party who signed then the security = of the system for the relying party is the security of the least = diligent signer. That is not true. The security of the system for the relying party is = the security of the signer that the domain owner chooses, and in a = market in which the cost differential is negligible (the likely market) = this will optimize for security of both parties (domain owner and = relying party). > As far as the registrar issue is concerned, There is a lot of = complexity there. What the customer thinks is a registrar may be a = reseller using an outsourced dns publisher. So that is three parties not = one.=20 Agreed, but the exclusive and public nature of DNS registration makes = this much less significant. > First possible line of attack is a Twitter style password reset = request. I'm not sure I understand what the attack vector is here in the DNS = model. In any event, it's far better security than thousands of trusted = (and often undisclosed) CAs/SubCAs/RAs. > Second is to claim a zone transfer. If bankofamerica.com isn't worried about this today on a basic = name-to-IP level, I think we have solved it to a significant degree. > Then there are typo attacks=20 Agreed. Totally unsolvable on the DNSSEC layer and a great example of = where CAs are still of critical importance in the domain-to-legal-entity = chain. > All entirely justifiable if all you are trying to do is to provide = almost as good security as dv ssl certs. No, _better_ than DV SSL certs (when it comes to domain-to-key mapping). > But what I am saying is that there is no reason not to have the option = of almost as good and very much better. ] The "very much better" part is essential, but it relies on the ability = of DNSSEC to ensure a superior domainname-to-owner mapping.= --Apple-Mail-14--1051953627 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii But my security is affected by = the place that mybank.com registers myemployer.com registers and so = on.

mybank.com will gravitate toward more = trustworthy registrars (because exclusivity promises actual increased = security), rather than the cheapest option (which is what the current DV = CA model encourages).

If the ui does not tell the = relying party who signed then the security of the system for the relying = party is the security of the least diligent = signer.

That is not true. =  The security of the system for the relying party is the security = of the signer that the domain owner chooses, and in a market in which = the cost differential is negligible (the likely market) this will = optimize for security of both parties (domain owner and relying = party).

As far as the registrar issue is = concerned, There is a lot of complexity there. What the customer thinks = is a registrar may be a reseller using an outsourced dns publisher. So = that is three parties not one. 
=
Agreed, but the exclusive and public nature of DNS = registration makes this much less significant.

First possible line of attack is = a Twitter style password reset = request.

I'm not sure I = understand what the attack vector is here in the DNS model.  In any = event, it's far better security than thousands of trusted (and often = undisclosed) CAs/SubCAs/RAs.

Second is to claim a zone = transfer.

If bankofamerica.com isn't worried = about this today on a basic name-to-IP level, I think we have solved it = to a significant degree.

Then there are typo attacks 
=
Agreed.  Totally unsolvable on the DNSSEC layer and = a great example of where CAs are still of critical importance in the = domain-to-legal-entity chain.

All entirely justifiable if all you are trying to do is to = provide almost as good security as dv ssl = certs.

No, _better_ than DV SSL certs = (when it comes to domain-to-key mapping).

But what I am saying is that there is no reason not to = have the option of almost as good and very much = better.
]
The "very much better" part = is essential, but it relies on the ability of DNSSEC to ensure a = superior domainname-to-owner mapping.
= --Apple-Mail-14--1051953627-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F04A3A6834 for ; Wed, 18 Aug 2010 22:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AudlBTY4gpC9 for ; Wed, 18 Aug 2010 22:39:05 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 868573A683C for ; Wed, 18 Aug 2010 22:39:01 -0700 (PDT) Received: by qwc9 with SMTP id 9so1431536qwc.31 for ; Wed, 18 Aug 2010 22:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=g75FTQ+LXpl5XFh0VkdCTMRjPeJKj+zjG61d44IU6KA=; b=GT3snrVZmJDz+aA8WX8nJP/tIwpGHRusJckygWxrnxoM0+q3SlZiFmbUI4Cp265uJU UqQNltpB8IJ91fRT1Ip9oLwr3mcamS3sSFS8ZYn0V0wW9aIIKfTQ55ZA5B3hxGEYdbhO TXGmaLPWvw/l6BIoeneST3YZHWJrv5s/cTvTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=iQe826O+1G14BV6gvJ+e2MgfcI8Z55u3P1VsO9hv4goNF2CU5vdNYTZMxZk56j9Szj dj4P0wW4mlcy+a7i1bCs4VXguYFINhiyiIjqlWkR1qLvuv/mNLF/8HfpSAkI621ZkFrm /V5AB1oRjWAMnG6rsFg88qzCQDSjdjI8aKh48= Received: by 10.229.190.69 with SMTP id dh5mr6850762qcb.95.1282196376205; Wed, 18 Aug 2010 22:39:36 -0700 (PDT) Received: from [10.0.1.8] (c-98-216-39-121.hsd1.ma.comcast.net [98.216.39.121]) by mx.google.com with ESMTPS id r36sm1307660qcs.39.2010.08.18.22.39.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 22:39:35 -0700 (PDT) References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <7B873166-52C0-4D25-B9D2-1B3D4C8BC827@princeton.edu> <0935306E-39BB-4001-BBA6-E2EF51C360F8@virtualized.org> Message-Id: From: Phillip Hallam-Baker To: David Conrad In-Reply-To: <0935306E-39BB-4001-BBA6-E2EF51C360F8@virtualized.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Thu, 19 Aug 2010 01:39:32 -0400 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 05:39:09 -0000 The charging issue is what the domain name owner is expected to pay to = have dnssec once this monopoly provider infrastructure is deployed. = ICANN extracts a rent on every domain name as does VeriSign in .com. Do = we have any guarantee that this rent will not increase in either case?=20= I would have thought that quite obvious but instead you pose = hypotheticals about how much ICANN is going to charge VeriSign, as if = that would be a concern for anyone. Sent from my iPad On Aug 18, 2010, at 11:51 PM, David Conrad wrote: > On Aug 18, 2010, at 7:51 PM, Steve Schultze wrote: >>> In the SSL cert case we do have an actual single root, the WebTrust = auditors. >> No, we have a single standard (well, two... one for EV and another = for everything else) which leaves huge areas of ambiguity and latitude = for browser/OS vendors to interpret compliance and tremendous holes when = it comes to god-like delegation after approval. >=20 > And, of course, WebTrust auditors could never be bribed... >=20 >> Are they charging anything for signing TLD DS records? =20 >=20 > Likely a rhetorical question, but just in case: no, ICANN does not = charge for accepting DS records (or anything else) from TLDs. VeriSign = similarly does not charge for accepting authorized root zone change = requests from ICANN, generating, signing, and transmitting the root zone = to the root server operators. And, of course, the root server operators = do not charge for serving the root zone on their servers. >=20 > Regards, > -drc >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 919D43A6887 for ; Wed, 18 Aug 2010 22:33:23 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfdUc47yrkPp for ; Wed, 18 Aug 2010 22:33:22 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 7F8BE3A6834 for ; Wed, 18 Aug 2010 22:33:15 -0700 (PDT) Received: by qyk1 with SMTP id 1so2666187qyk.10 for ; Wed, 18 Aug 2010 22:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=CvzjsyOu5Xse5El2BmvF1083vw1abwOHUBvS+20Gi0k=; b=ueBVSXPic6LCDHqSDQDuZAw4Zxeyx2GYMe1cCEP4jKfGPwVA/QWXnMTrKAICSJhebP hVCPuw+CFc0QkFzAitNoYFtBNeLAp3bNe2fTLS2vhPq0ldpKMtORiU1GK9+lxEu1aSwi UPVjNmI/sGHmc6h7HdTxgWjk0DNIPnBLdCktM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=n5oBmb1zu/mfJbEf49/N8jcReUFONXQB8+YgNu6K5mu070yu1ACT4KfzypV45GOyhU t7KMxqidD6SFdD11GAw2xOuDtcqeQeTnByg9NEyraKZsJycKA9FPcMtVP0XoFsYdcEyk tQKs/I4bOaXPKNDul3I7GbZf67mZnIcBl5ESg= Received: by 10.229.229.83 with SMTP id jh19mr6828919qcb.76.1282196022360; Wed, 18 Aug 2010 22:33:42 -0700 (PDT) Received: from [10.0.1.8] (c-98-216-39-121.hsd1.ma.comcast.net [98.216.39.121]) by mx.google.com with ESMTPS id t24sm1308741qcs.11.2010.08.18.22.33.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 22:33:41 -0700 (PDT) References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> Message-Id: <25610D95-3C55-4920-B33B-B420E8CF639B@gmail.com> From: Phillip Hallam-Baker To: Steve Schultze In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Thu, 19 Aug 2010 01:33:37 -0400 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 05:33:24 -0000 The point is that I get to choose where to register hallambaker.com But my security is affected by the place that mybank.com registers = myemployer.com registers and so on. If the ui does not tell the relying party who signed then the security = of the system for the relying party is the security of the least = diligent signer. People are asserting that the dnssec design as it stands addresses this = problem when it does not. But that does not mean that we can't add in = some pieces so that it does.=20 As far as the registrar issue is concerned, There is a lot of complexity = there. What the customer thinks is a registrar may be a reseller using = an outsourced dns publisher. So that is three parties not one.=20 First possible line of attack is a Twitter style password reset request. Second is to claim a zone transfer. Then there are typo attacks=20 All entirely justifiable if all you are trying to do is to provide = almost as good security as dv ssl certs. But what I am saying is that = there is no reason not to have the option of almost as good and very = much better. There are holes we need to plug in pkix as well.=20 Sent from my iPad On Aug 19, 2010, at 12:53 AM, Steve Schultze wrote: > On Aug 19, 2010, at 12:49 AM, Phillip Hallam-Baker wrote: >> I can choose the most diligent registrar in the world. But that won't = do anything to improve the quality of the information I have to rely on >=20 > I don't believe you are correct, but I would welcome your = clarification if I misunderstand. >=20 > Once a domain is registered, even if BadGuy goes to EvilRegistrar, he = can't obtain control of that zone. What is your exploit that makes this = possible? > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D513A6894 for ; Wed, 18 Aug 2010 22:10:14 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK9gFwChOdov for ; Wed, 18 Aug 2010 22:10:09 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 023893A6867 for ; Wed, 18 Aug 2010 22:10:08 -0700 (PDT) Received: by qyk1 with SMTP id 1so2652245qyk.10 for ; Wed, 18 Aug 2010 22:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=vkxCw2J+HzC3ZnvAKVMYm18sAG3OREtbezEvm1nSGFo=; b=fk1/meGAHGIpLV49LIsZ1cxBNcgTY5jvP1zZcJuHnS9mZGhB/1reGxEC2K2pQkq0uJ NVA9nijD8X8qKeYYiham/OZOIoVVxgi/OUIZAVSIbA3FUhFCQXt2mEVmMj9vvbauEdZi Zparf7j7H0FPvL4uwR44dyjmfRz1apnnk+n5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=BH0zHkbvDEPehNtGCX06pyy1xQ/Kaxng9occjTP63jQgaOdMw4mv9fmMOrjQ7YblVO ACfINPGG47+W/YozkC+H/oocv6UbzyA+fJcE7hulPdWhrvL51L5xPt+rz9MnSXZMt/DX 9+fYEDRT5h3qDs37uKzrRRMPf898JlWxreKRs= Received: by 10.229.215.67 with SMTP id hd3mr6798096qcb.74.1282194643536; Wed, 18 Aug 2010 22:10:43 -0700 (PDT) Received: from [10.0.1.8] (c-98-216-39-121.hsd1.ma.comcast.net [98.216.39.121]) by mx.google.com with ESMTPS id e6sm1291104qcr.5.2010.08.18.22.10.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 22:10:42 -0700 (PDT) References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <20100818225922.5b876717@teensy> Message-Id: <4BD940B1-8A5E-4E0C-99A8-97945CF8873B@gmail.com> From: Phillip Hallam-Baker To: "Perry E. Metzger" In-Reply-To: <20100818225922.5b876717@teensy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Thu, 19 Aug 2010 01:10:39 -0400 Cc: "keyassure@ietf.org" , Paul Hoffman Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 05:10:20 -0000 Perry=20 It has taken fifteen years to get to this point. A large part of the = reason for that delay was the refusal to consider real world constraints = that did not fit the abstract technical model It took eight years to fix the opt in issue. It took five years to fix = the eu privacy directive issue. Both took too long because people didn't = want to accept the possibility of a problem. We have a proposed charter that asserts that the benefit of dnssec lies = in having a single root of trust because that means fewer points of = failure. I am pointing out that these claims are not actually true. If = people don't want to argue the point then delete the unnecessary claims = from the charter. Don't forget that in the originally proposed and deployed ssl model that = there was a single root of trust. It didn't stay that way for long. It = was an unstable condition. Sent from my iPad On Aug 18, 2010, at 10:59 PM, "Perry E. Metzger" = wrote: > On Wed, 18 Aug 2010 22:21:32 -0400 > Phillip Hallam-Baker wrote: >> Ok let's look at what the trust path is for DNSSEC >>=20 >> Take www.example.com >>=20 >> ICANN is accountable to whom? >>=20 >> VeriSign as the registry is maybe accountable to ICANN but not to the >> example.com domain name owner >=20 > In the current CA model, every single CA disclaims all > liability. There is thus no reduction in function there. >=20 > In any case, if you dislike the idea, you are not obligated to use > it. I would leave the people who want to do such things alone to get > their work done. >=20 > Perry Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 947E63A6858 for ; Wed, 18 Aug 2010 21:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLjHf115P+0K for ; Wed, 18 Aug 2010 21:52:46 -0700 (PDT) Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id BA7683A67A1 for ; Wed, 18 Aug 2010 21:52:44 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7J4rImc028724 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 19 Aug 2010 00:53:18 -0400 Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7J4rHSq006230 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 Aug 2010 00:53:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Schultze In-Reply-To: <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> Date: Thu, 19 Aug 2010 00:53:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1077) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6078 signatures=637975 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008180265 Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 04:52:47 -0000 On Aug 19, 2010, at 12:49 AM, Phillip Hallam-Baker wrote: > I can choose the most diligent registrar in the world. But that won't = do anything to improve the quality of the information I have to rely on I don't believe you are correct, but I would welcome your clarification = if I misunderstand. Once a domain is registered, even if BadGuy goes to EvilRegistrar, he = can't obtain control of that zone. What is your exploit that makes this = possible?= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5367F3A6834 for ; Wed, 18 Aug 2010 21:49:01 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVn2LiVvwOkp for ; Wed, 18 Aug 2010 21:49:00 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id B08883A684F for ; Wed, 18 Aug 2010 21:48:59 -0700 (PDT) Received: by qyk9 with SMTP id 9so1409233qyk.10 for ; Wed, 18 Aug 2010 21:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=rP0uQZUseXth0WyYaZF7/O7A+FBOmAeDC7X9eO8AjCo=; b=vGw8OIFri0X3j1h8UnzFHJ8wJqnPbiwxEwzSAgfHi1BsrTwN/RFYw0MzdNsskvnQXB /nrxOSAupFUhPSz1kKKo6Ua/JcUdEb5AYOg37kWAdwuYRWQObHiK03oD8DX/KuFYMix0 ywuvB8v4DCyBAH8hEBGkF2ACpKNczFClpBpNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=bndsuA7U4tunEzNnIVsZEnMpik2wRmNUeig4/VUmcfcJbHYbDGoxIZ5bFQ4IRsBtDk 5Y76Q+Lu7bHZQp7+IbRcElZG2gWqaLOLz2tolqiVC2OoivZvEOVQzVmjGzrLsnKw/p+d gURoPJcz4aXV33JEk8Ss0HTTdxMsSJFl2Asa8= Received: by 10.224.80.147 with SMTP id t19mr6056313qak.166.1282193374142; Wed, 18 Aug 2010 21:49:34 -0700 (PDT) Received: from [10.0.1.8] (c-98-216-39-121.hsd1.ma.comcast.net [98.216.39.121]) by mx.google.com with ESMTPS id t1sm1266566qcs.45.2010.08.18.21.49.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 21:49:32 -0700 (PDT) References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> Message-Id: <86B2F781-1896-42DB-90E7-A7CDC1E80B0C@gmail.com> From: Phillip Hallam-Baker To: David Conrad In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Thu, 19 Aug 2010 00:49:29 -0400 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 04:49:01 -0000 You make a big mistake here when you talk about choosing a registrar = wisely You are looking at the problem from the point of view of someone putting = keys in. The correct way to look at the issue if you want to make the = comparison to ssl CAs is from the point of view of someone who is = relying on the keys. And there they have no way to control who the = registrar is. Unlike in ssl you don't even know who did the validation = if at all. I can choose the most diligent registrar in the world. But that won't do = anything to improve the quality of the information I have to rely on On Aug 18, 2010, at 11:38 PM, David Conrad wrote: > [Just joined this list and may not be staying long if this is typical = subject matter] >=20 > On Aug 18, 2010, at 7:21 PM, Phillip Hallam-Baker wrote: >> ICANN is accountable to whom? >=20 > Depends on which part of ICANN you're looking at. In the case of = anything having to do with the IANA function (which managing the KSK is = deemed), ICANN is accountable to the U.S. Dept. of Commerce, National = Telecommunications and Information Administration, via the IANA = functions contract (actually, the contract is with NOAA, but it is NTIA = that cares. Deeply). >=20 >> VeriSign as the registry is maybe accountable to ICANN but not to the = example.com domain name owner >=20 > Accountability for what exactly? VeriSign is contractually obligated = to ICANN to be accountable for various things. >=20 >> Then we have the box which people are naively labeling "the" = registrar >=20 > Yes. Choose your registrar wisely. Caveat emptor and all that. >=20 >> And we are not finished yet since the actual operations of many of = those registrars is in turn outsourced to a dns hosting specialist. = Which is good in some ways because there are fewer of those than there = are registrars. >=20 > If you want to fully trust the contents of your domain, you sign it = yourself. Period. >=20 >> All told we have several thousand parties who could potentially touch = a DNS record. Names are transferred between these registrars on a = continuous basis.=20 >=20 > So you, as the admin of example.com, give your DS to your registrar to = have it inserted into the COM zone. You chose your registrar poorly and = they mangle your DS in a nefarious attempt to seize control of your zone = (or something). Your evil registrar updates the .COM zone and = (eventually, when is a bit indeterminate at least currently), VeriSign = publishes the updated zone. >=20 > And you don't notice that the DS that was supplied doesn't match what = showed up in the .COM zone and stamp your foot petulantly (or = something)? How does that work again? >=20 >> I won't defend how some CAs issue certs. But what I won't accept is = the idea that the ICANN scheme is intrinsically superior. >=20 > It is superior in the sense that you have a _much_ more limited set of = players and the selection of players (that is, who can be a registry) is = typically a bit more public. >=20 >> ICANN has enough difficulty ejecting registrars being run by = organized crime. >=20 > I'd suggest not choosing a registrar run by organized crime. >=20 >> They are suddenly going to acquire the expertise to run a global PKI = better than the existing scheme and do so for free? >=20 > ICANN maintains the KSK for the root of the DNS. It has demonstrated = the expertise to do this (at least IMNSHO). The fact that some folks = believe an alternate PKI can be established using DNSSEC with a trusted = root signed by VeriSign (not ICANN) is somewhat unrelated to the fact = that ICANN signs VeriSign's ZSKs with the KSK they maintain. >=20 > And yes, ICANN does maintain the KSK for the root of the DNS "for = free". That is, if you consider the fees imposed by ICANN on the = registries and registrars to be completely inconsequential. >=20 >> Since when has ICANN done anything for free? They charge $50,000 to = merely apply for a tld that they may well reject. >=20 > Actually, it is $185,000 last I looked. >=20 >> They may be called a non profit but they certainly pay some handsome = salaries.=20 >=20 > So... keyassure is an yet another ICANN-bashing list? O joy, O = rapture. What does the salary ICANN pays have to do with anything = relevant to what I thought this list was going to be discussing? >=20 > Regards, > -drc >=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0F83A6A93 for ; Wed, 18 Aug 2010 20:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWPoi9P66paS for ; Wed, 18 Aug 2010 20:50:50 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 7B7593A6817 for ; Wed, 18 Aug 2010 20:50:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 0E9EDDC26E2; Wed, 18 Aug 2010 20:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3salwKx7zCVX; Wed, 18 Aug 2010 20:51:14 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 42D08DC26D6; Wed, 18 Aug 2010 20:51:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <7B873166-52C0-4D25-B9D2-1B3D4C8BC827@princeton.edu> Date: Wed, 18 Aug 2010 20:51:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0935306E-39BB-4001-BBA6-E2EF51C360F8@virtualized.org> References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <7B873166-52C0-4D25-B9D2-1B3D4C8BC827@princeton.edu> To: Steve Schultze X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 03:50:51 -0000 On Aug 18, 2010, at 7:51 PM, Steve Schultze wrote: >> In the SSL cert case we do have an actual single root, the WebTrust = auditors. > No, we have a single standard (well, two... one for EV and another for = everything else) which leaves huge areas of ambiguity and latitude for = browser/OS vendors to interpret compliance and tremendous holes when it = comes to god-like delegation after approval. And, of course, WebTrust auditors could never be bribed... > Are they charging anything for signing TLD DS records? =20 Likely a rhetorical question, but just in case: no, ICANN does not = charge for accepting DS records (or anything else) from TLDs. VeriSign = similarly does not charge for accepting authorized root zone change = requests from ICANN, generating, signing, and transmitting the root zone = to the root server operators. And, of course, the root server operators = do not charge for serving the root zone on their servers. Regards, -drc Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21973A6A96 for ; Wed, 18 Aug 2010 20:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK6ro6PfpUuH for ; Wed, 18 Aug 2010 20:41:42 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id C8BFE3A6A93 for ; Wed, 18 Aug 2010 20:41:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 23A3BDC2608; Wed, 18 Aug 2010 20:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyOXrBmWpfEo; Wed, 18 Aug 2010 20:42:16 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 6A492DC25FD; Wed, 18 Aug 2010 20:42:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <9AA3BC53-A3E1-46AC-B890-E1487283D13A@gmail.com> Date: Wed, 18 Aug 2010 20:42:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <20100818204352.GB94188@shinkuro.com> <9AA3BC53-A3E1-46AC-B890-E1487283D13A@gmail.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 03:41:43 -0000 On Aug 18, 2010, at 7:26 PM, Phillip Hallam-Baker wrote: > I want to use dnssec without the ICANN root.=20 Feel free. There are (currently) only about 300 TLD trust anchors = you'll have to keep track of if all the TLDs started signing. ICANN says = they'll be adding no more than about 1000/year. You'll have to figure = out a way of securely fetching the trust anchors from the TLD admins who = sign their zones to install into your validating resolver, but that's a = minor detail. A single root of trust _can be_ better since there are less parties to = vet and audit (1 versus many). However, as I said, if you don't want to = trust ICANN, VeriSign, and the US Government, you don't have to. Regards, -drc Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11D13A6817 for ; Wed, 18 Aug 2010 20:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=-1.847, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liMYXG4Q8i0n for ; Wed, 18 Aug 2010 20:37:39 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id B73313A6909 for ; Wed, 18 Aug 2010 20:37:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id E6220DC2572; Wed, 18 Aug 2010 20:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjINoSsVgy41; Wed, 18 Aug 2010 20:38:09 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 8FC49DC2562; Wed, 18 Aug 2010 20:38:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Wed, 18 Aug 2010 20:38:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 03:37:41 -0000 [Just joined this list and may not be staying long if this is typical = subject matter] On Aug 18, 2010, at 7:21 PM, Phillip Hallam-Baker wrote: > ICANN is accountable to whom? Depends on which part of ICANN you're looking at. In the case of = anything having to do with the IANA function (which managing the KSK is = deemed), ICANN is accountable to the U.S. Dept. of Commerce, National = Telecommunications and Information Administration, via the IANA = functions contract (actually, the contract is with NOAA, but it is NTIA = that cares. Deeply). > VeriSign as the registry is maybe accountable to ICANN but not to the = example.com domain name owner Accountability for what exactly? VeriSign is contractually obligated to = ICANN to be accountable for various things. > Then we have the box which people are naively labeling "the" registrar Yes. Choose your registrar wisely. Caveat emptor and all that. > And we are not finished yet since the actual operations of many of = those registrars is in turn outsourced to a dns hosting specialist. = Which is good in some ways because there are fewer of those than there = are registrars. If you want to fully trust the contents of your domain, you sign it = yourself. Period. > All told we have several thousand parties who could potentially touch = a DNS record. Names are transferred between these registrars on a = continuous basis.=20 So you, as the admin of example.com, give your DS to your registrar to = have it inserted into the COM zone. You chose your registrar poorly and = they mangle your DS in a nefarious attempt to seize control of your zone = (or something). Your evil registrar updates the .COM zone and = (eventually, when is a bit indeterminate at least currently), VeriSign = publishes the updated zone. And you don't notice that the DS that was supplied doesn't match what = showed up in the .COM zone and stamp your foot petulantly (or = something)? How does that work again? > I won't defend how some CAs issue certs. But what I won't accept is = the idea that the ICANN scheme is intrinsically superior. It is superior in the sense that you have a _much_ more limited set of = players and the selection of players (that is, who can be a registry) is = typically a bit more public. > ICANN has enough difficulty ejecting registrars being run by organized = crime. I'd suggest not choosing a registrar run by organized crime. > They are suddenly going to acquire the expertise to run a global PKI = better than the existing scheme and do so for free? ICANN maintains the KSK for the root of the DNS. It has demonstrated = the expertise to do this (at least IMNSHO). The fact that some folks = believe an alternate PKI can be established using DNSSEC with a trusted = root signed by VeriSign (not ICANN) is somewhat unrelated to the fact = that ICANN signs VeriSign's ZSKs with the KSK they maintain. And yes, ICANN does maintain the KSK for the root of the DNS "for free". = That is, if you consider the fees imposed by ICANN on the registries = and registrars to be completely inconsequential. > Since when has ICANN done anything for free? They charge $50,000 to = merely apply for a tld that they may well reject. Actually, it is $185,000 last I looked. > They may be called a non profit but they certainly pay some handsome = salaries.=20 So... keyassure is an yet another ICANN-bashing list? O joy, O rapture. = What does the salary ICANN pays have to do with anything relevant to = what I thought this list was going to be discussing? Regards, -drc Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875933A6A97 for ; Wed, 18 Aug 2010 19:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9UYFqoP0iA4 for ; Wed, 18 Aug 2010 19:58:49 -0700 (PDT) Received: from hacklheber.piermont.com (hacklheber.piermont.com [166.84.7.14]) by core3.amsl.com (Postfix) with ESMTP id 18F563A6A96 for ; Wed, 18 Aug 2010 19:58:49 -0700 (PDT) Received: from bellman.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 7E53328CFC5; Wed, 18 Aug 2010 22:59:23 -0400 (EDT) Received: from teensy (teensy.cb.piermont.com [10.160.2.108]) by bellman.cb.piermont.com (Postfix) with ESMTP id 47DEF2DE067; Wed, 18 Aug 2010 22:59:23 -0400 (EDT) Date: Wed, 18 Aug 2010 22:59:22 -0400 From: "Perry E. Metzger" To: Phillip Hallam-Baker Message-ID: <20100818225922.5b876717@teensy> In-Reply-To: References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.20.1; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "keyassure@ietf.org" , Paul Hoffman Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 02:58:50 -0000 On Wed, 18 Aug 2010 22:21:32 -0400 Phillip Hallam-Baker wrote: > Ok let's look at what the trust path is for DNSSEC > > Take www.example.com > > ICANN is accountable to whom? > > VeriSign as the registry is maybe accountable to ICANN but not to the > example.com domain name owner In the current CA model, every single CA disclaims all liability. There is thus no reduction in function there. In any case, if you dislike the idea, you are not obligated to use it. I would leave the people who want to do such things alone to get their work done. Perry Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17D53A6A9A for ; Wed, 18 Aug 2010 19:51:14 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TUGcomZ+2lv for ; Wed, 18 Aug 2010 19:51:13 -0700 (PDT) Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id 6E3263A6A98 for ; Wed, 18 Aug 2010 19:51:13 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7J2pllm002683 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 18 Aug 2010 22:51:47 -0400 Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7J2pkSq010881 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 Aug 2010 22:51:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Schultze In-Reply-To: Date: Wed, 18 Aug 2010 22:51:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7B873166-52C0-4D25-B9D2-1B3D4C8BC827@princeton.edu> References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1077) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6078 signatures=637975 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008180243 Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 02:51:14 -0000 > On Aug 18, 2010, at 4:32 PM, Paul Hoffman = wrote: >=20 >> At 3:55 PM -0400 8/18/10, Phillip Hallam-Baker wrote: >>> With DNSSEC alone we have a domain linkage, but no accountability = for it. >>=20 >> This is completely incorrect. The accountability is to "the same = person who gave you the A record that you are about to use to go to the = site". On Aug 18, 2010, at 10:21 PM, Phillip Hallam-Baker wrote: > First off there are a few hundred ICANN registered registrars. = [etc...] The architecture is exclusive, and in the case where there are possible = nefarious means for gaining control of someone else's zone such = shenanigans are highly detectable (they are inherently public) and = dispute processes are well-established and have been relied upon by = everyone using the web for a long time. > Definitely less than is required to operate a CA where there is a = WEbTrust audit requirement. As a nitpick, WebTrust is not a requirement for CA approval (ETSI and = ANSI standards are also accepted by the major vendors). The standards = for who can conduct audits are somewhat arbitrary (why CPAs?) and aged = (the non-EV standards were designed to be provisional and never = updated). But the more important reasons why the DNS approach provides advantages = are the reasons I gave above (exclusivity and publicity). That is not to say of course that WebTrust-audited CAs don't have a = critical role going forward... especially when it comes to EV and the = like. Their role is complimentary. However, the domain linkage = function of DNSSEC-validated assertions is as good as (well, better = than) today's DV certs. > I won't defend how some CAs issue certs. But what I won't accept is = the idea that the ICANN scheme is intrinsically superior. It has more = moving parts, more potential points of failure and huge areas of = ambiguity. With respect to domain validation, it has fewer points of failure. The = points of failure are each node down the hierarchy (and only one path = down is allowed). The points of failure in CA DV certs are 300+ CAs = plus thousands of Subordinate CAs (often undisclosed) plus thousands = more RAs (also undisclosed). > In the SSL cert case we do have an actual single root, the WebTrust = auditors. No, we have a single standard (well, two... one for EV and another for = everything else) which leaves huge areas of ambiguity and latitude for = browser/OS vendors to interpret compliance and tremendous holes when it = comes to god-like delegation after approval. > ICANN has enough difficulty ejecting registrars being run by organized = crime. They are suddenly going to acquire the expertise to run a global = PKI better than the existing scheme and do so for free? Exclusivity allows site operators to choose the most trustworthy = registrar... hopefully initiating a race to the top instead of today's = CA DV race to the bottom. > Since when has ICANN done anything for free? They charge $50,000 to = merely apply for a tld that they may well reject. They may be called a = non profit but they certainly pay some handsome salaries.=20 Are they charging anything for signing TLD DS records? That's the only = relevant question in this context. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613D53A67B1 for ; Wed, 18 Aug 2010 19:25:40 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TT5ILphijhQ for ; Wed, 18 Aug 2010 19:25:39 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 6C5833A6781 for ; Wed, 18 Aug 2010 19:25:39 -0700 (PDT) Received: by pvg7 with SMTP id 7so572989pvg.31 for ; Wed, 18 Aug 2010 19:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=QYY70V6fMXKiJvVA7PNLwXurCddJYiv6MdFxLzI481g=; b=Nq1xp2R3Okl+qbeuxus6ZcCByB6L7UWE8797Wmdttg3y/5QtFwBQCuOyJo5+WGNa0n Av1zAP6bbvZ9MgbOs7+xjdhswFpjf2XY3R9v/0Qa5zLy74GRtlcBK3Kvd8VYwafEB/Kq 6Q6p5Mt/5eg0mksN92/OBtA0mqCdyFJXNo1Cs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=EhtaLqIta8yK/R0WrxlM2gfeVTOVihQ9lKCuYYe998+ybEuWw8RxXGidGr3pHlrl9+ vxhidHMWDBiseGJgfCyLBFbs5SYMUOUsogPVPzmBjdkCedsAuiiK1E81K+BtJvV6/3Qu kLw/xM/uuhRjjXbP8Zl6ksVfG+OYTbImzJEuo= Received: by 10.142.112.13 with SMTP id k13mr1414730wfc.300.1282184774174; Wed, 18 Aug 2010 19:26:14 -0700 (PDT) Received: from [172.16.31.21] (wsip-70-168-8-125.ri.ri.cox.net [70.168.8.125]) by mx.google.com with ESMTPS id t11sm1077813wfc.4.2010.08.18.19.26.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 19:26:12 -0700 (PDT) References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <20100818204352.GB94188@shinkuro.com> Message-Id: <9AA3BC53-A3E1-46AC-B890-E1487283D13A@gmail.com> From: Phillip Hallam-Baker To: Andrew Sullivan In-Reply-To: <20100818204352.GB94188@shinkuro.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Wed, 18 Aug 2010 22:26:06 -0400 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 02:25:40 -0000 People are constantly asserting something that is not true. If you want to make statements asserting how the single root of trust is = better. Then expect to hear the opposite point of view. We have a proposed charter making tendentious statements on this topic, = so they are certainly in scope. You can't expect to take swipes at = people and then cry uncle when they defend themselves. I want to use dnssec without the ICANN root.=20 Sent from my iPad On Aug 18, 2010, at 4:43 PM, Andrew Sullivan wrote: > On Wed, Aug 18, 2010 at 04:18:25PM -0400, Paul Wouters wrote: >> But really, the discussion of whether I can trust a TLD operator more = then >> a CA operator is outside the scope of this list. I believe what is = desired >> here is a way to use the TLD operator without a CA operator. We = already have >> the reverse case for those interested in that. >=20 > Hear, hear. We don't need to debate whether one approach is better > than the other. We're not writing signature-style-choices-bcp. The > point is to write something that works interoperably provided that you > accept the premise that what you want to use is DNSSEC. >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 659F53A6990 for ; Wed, 18 Aug 2010 19:21:08 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzLHOu90LhGt for ; Wed, 18 Aug 2010 19:21:07 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 3ED213A6781 for ; Wed, 18 Aug 2010 19:21:07 -0700 (PDT) Received: by pwi1 with SMTP id 1so676237pwi.31 for ; Wed, 18 Aug 2010 19:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=eLMeFpubBU2a6drXG8SRVL5TCYjlg2HShegsRPFMcCs=; b=PN95mZ4yhQ4bYCcNPXVZNKgKXW2tDAKlVMlCeE/lsPBmAK98gGGiuEuLiht0TXy1IS nGSoCtxtHRnnjlj5A89v/j6NuYPlU+4cEPqe9R2GrweNPNm0QF1lNRe9Xl04ISenu4WM mgC3jo8aSoc8shVciGNsQ7FiOPW+iEjrMpMDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=Uig+PJ2t9QzYjRoey8Vup8n94CHUG6BLxnf8jAMOYbhymzWJ3USUfdBYEhP6w0U9jT X8UXuogPatxYK4gXdGdldsFvCMdywVtUUlHaLG+LlsJxndTbSAlX8yjznTbxk1n0TMPT Xe1ft/ci7iq3nvyQoEoZcWEuiJ4/e+WFkS+tw= Received: by 10.114.108.15 with SMTP id g15mr10554000wac.52.1282184502301; Wed, 18 Aug 2010 19:21:42 -0700 (PDT) Received: from [172.16.31.21] (wsip-70-168-8-125.ri.ri.cox.net [70.168.8.125]) by mx.google.com with ESMTPS id d39sm1641499wam.4.2010.08.18.19.21.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 19:21:41 -0700 (PDT) References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> Message-Id: From: Phillip Hallam-Baker To: Paul Hoffman In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Wed, 18 Aug 2010 22:21:32 -0400 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 02:21:08 -0000 Ok let's look at what the trust path is for DNSSEC Take www.example.com ICANN is accountable to whom? VeriSign as the registry is maybe accountable to ICANN but not to the = example.com domain name owner Then we have the box which people are naively labeling "the" registrar First off there are a few hundred ICANN registered registrars. Some of = which are outright criminal. And beyond that you have an even greater = number of resellers that the key holder thinks is their registrar but is = simply a reseller And we are not finished yet since the actual operations of many of those = registrars is in turn outsourced to a dns hosting specialist. Which is = good in some ways because there are fewer of those than there are = registrars. All told we have several thousand parties who could potentially touch a = DNS record. Names are transferred between these registrars on a = continuous basis.=20 Forget accountability, I don't think anyone could claim to have a = comprehensive enumeration. Certainly the authentication required to get = ICANN credentials is not very great, arguably not even as serious as the = requirement to get an EV certain. Definitely less than is required to = operate a CA where there is a WEbTrust audit requirement. I won't defend how some CAs issue certs. But what I won't accept is the = idea that the ICANN scheme is intrinsically superior. It has more moving = parts, more potential points of failure and huge areas of ambiguity. In = the SSL cert case we do have an actual single root, the WebTrust = auditors. Can anyone give a reason for why the ICANN system won't fail = in precisely the same way? ICANN has enough difficulty ejecting registrars being run by organized = crime. They are suddenly going to acquire the expertise to run a global = PKI better than the existing scheme and do so for free? Since when has ICANN done anything for free? They charge $50,000 to = merely apply for a tld that they may well reject. They may be called a = non profit but they certainly pay some handsome salaries.=20 Sent from my iPad On Aug 18, 2010, at 4:32 PM, Paul Hoffman wrote: > At 3:55 PM -0400 8/18/10, Phillip Hallam-Baker wrote: >> With DNSSEC alone we have a domain linkage, but no accountability for = it. >=20 > This is completely incorrect. The accountability is to "the same = person who gave you the A record that you are about to use to go to the = site". >=20 > --Paul Hoffman, Director > --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB143A67C3 for ; Wed, 18 Aug 2010 17:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.741 X-Spam-Level: X-Spam-Status: No, score=-102.741 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK+6A9mE59SR for ; Wed, 18 Aug 2010 17:12:41 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id EFDD63A68C7 for ; Wed, 18 Aug 2010 17:12:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 892013E4096; Thu, 19 Aug 2010 01:13:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1282176794; bh=bGbbUPRWMWZksr wMA1W8uY5BxaOmQTd728bLJfE0vkY=; b=sEDr0gkJygnrMIKQJ/tNe3Pd+Inr5u DReAsLt7Z5UwO2PrOOMRRJsC1EPk/qQvuMzbI6NYNyLh9aNsSJZL9bNqhJShT8dp 7fytKzgrIS/snvt3HABBo5ta8s9BsT4Jx9T53Z2XXEd+EMPkkd0Kq+omO/ylR5Rt WL9N8nGNG3w2pKpDhe9AU/gI6HCEZEsm/92sYavL2YmiJ3DfHR02VYinKv7me+Zg KkPn8p2hWgaAdH2krGZijdKVosDIrqty4Yuq9gzeCYCUV3pzQH7zTzTMAuu19wan fFODU0DdrvdgUNuO7AngJau7+nDGpfDleY+xYLSzbElGyfl/vJGzB4iw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Difabqglc-Q1; Thu, 19 Aug 2010 01:13:14 +0100 (IST) Received: from [10.87.48.3] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3A17F3E4090; Thu, 19 Aug 2010 01:13:13 +0100 (IST) Message-ID: <4C6C7718.40003@cs.tcd.ie> Date: Thu, 19 Aug 2010 01:13:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <4C6B90C5.8080503@nic.cz> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Key linkage draft, -00 edition X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 00:12:42 -0000 Quick question: did you consider DKIM key records for this? (With a new "s=" value in the TXT RR.) If so, why don't they rate a mention? If not, maybe worth a look? S. On 18/08/10 15:45, Paul Hoffman wrote: > Greetings again. A gang of us created a draft that pulls together some of the many ideas that have been floating around. There are multiple options for some features, so we chose one option in each category and started an appendix to document the choices. > > > > Discussion is welcome. Please don't assume that any of the options are set in stone, although note that changing some options might also require changing other options at the same time. In particular, I think my idea of listing ports is going to go away, given that few sites run services on different ports but keep the same domain name. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931C53A6828 for ; Wed, 18 Aug 2010 16:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.076 X-Spam-Level: X-Spam-Status: No, score=-101.076 tagged_above=-999 required=5 tests=[AWL=0.970, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7kt07S2w8CP for ; Wed, 18 Aug 2010 16:41:56 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CF0603A679F for ; Wed, 18 Aug 2010 16:41:56 -0700 (PDT) Received: from [10.20.30.158] (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 o7INgTcG020419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Aug 2010 16:42:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <20100818204352.GB94188@shinkuro.com> <4C6C52FA.3070207@stpeter.im> <4C6C5F7D.9040109@stpeter.im> Date: Wed, 18 Aug 2010 16:42:28 -0700 To: Paul Wouters , Peter Saint-Andre From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 23:41:57 -0000 At 6:46 PM -0400 8/18/10, Paul Wouters wrote: >On Wed, 18 Aug 2010, Peter Saint-Andre wrote: > >>>Perhaps some clarification could be made. Perhaps some container formats of >>>PKIX might be used, but not the trust model of external CA's? (If you would >>>do that, this would just become a repeat of RFC 4398) >> >>Ah, what I meant is that just because you use DNSSEC to get information >>out of DNS doesn't mean you can't use PKIX certificates during TLS >>negotiation with an application service. > >Oh sure. you could do BTNS channel binding too an upgrade some TLS connection >to a more trusted state based on external authentication. But that is all >outside the scope of what to put in a new type of DNS RR record. And we >should not limit a new RR type to REQUIRE external authentication. If you want to do something that requires a protocol change to TLS at the same time (instead of just a processing policy change), sure. Such a requirement is not the only choice, however. Our draft leaves the PKIX cert in TLS as-is, but adds an external binding of the key to the domain name by the same organization that is telling you other information about the domain name, such as the IP address. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BF93A6A59 for ; Wed, 18 Aug 2010 15:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMDgPrQ8lOBE for ; Wed, 18 Aug 2010 15:45:55 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id DE0533A687D for ; Wed, 18 Aug 2010 15:45:54 -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 594E4C17D; Wed, 18 Aug 2010 18:46:29 -0400 (EDT) Date: Wed, 18 Aug 2010 18:46:28 -0400 (EDT) From: Paul Wouters To: Peter Saint-Andre In-Reply-To: <4C6C5F7D.9040109@stpeter.im> Message-ID: References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <20100818204352.GB94188@shinkuro.com> <4C6C52FA.3070207@stpeter.im> <4C6C5F7D.9040109@stpeter.im> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 22:45:55 -0000 On Wed, 18 Aug 2010, Peter Saint-Andre wrote: >> Perhaps some clarification could be made. Perhaps some container formats of >> PKIX might be used, but not the trust model of external CA's? (If you would >> do that, this would just become a repeat of RFC 4398) > > Ah, what I meant is that just because you use DNSSEC to get information > out of DNS doesn't mean you can't use PKIX certificates during TLS > negotiation with an application service. Oh sure. you could do BTNS channel binding too an upgrade some TLS connection to a more trusted state based on external authentication. But that is all outside the scope of what to put in a new type of DNS RR record. And we should not limit a new RR type to REQUIRE external authentication. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50283A6A98 for ; Wed, 18 Aug 2010 15:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAd4xg5Pr8Dr for ; Wed, 18 Aug 2010 15:31:56 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 319013A67FC for ; Wed, 18 Aug 2010 15:31:56 -0700 (PDT) Received: from squire.local (dsl-140-248.dynamic-dsl.frii.net [216.17.140.248]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2427440074; Wed, 18 Aug 2010 16:34:17 -0600 (MDT) Message-ID: <4C6C5F7D.9040109@stpeter.im> Date: Wed, 18 Aug 2010 16:32:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Paul Wouters References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <20100818204352.GB94188@shinkuro.com> <4C6C52FA.3070207@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 22:31:57 -0000 On 8/18/10 4:00 PM, Paul Wouters wrote: > On Wed, 18 Aug 2010, Peter Saint-Andre wrote: > >>> Hear, hear. We don't need to debate whether one approach is better >>> than the other. We're not writing signature-style-choices-bcp. The >>> point is to write something that works interoperably provided that you >>> accept the premise that what you want to use is DNSSEC. >> >> Which might mean using both DNSSEC and PKIX -- the choice is not >> either-or. > > I think previous attempts explicitely included PKIX, and the efforts > died because of it. > > I was not at the IETF in Maastricht, so I did not attend the BOF, but I > don't > think commiting to a CA/X.509 will be very useful. the PKIX people will > (again) > say "we already have CA's for that". > > Perhaps some clarification could be made. Perhaps some container formats of > PKIX might be used, but not the trust model of external CA's? (If you would > do that, this would just become a repeat of RFC 4398) Ah, what I meant is that just because you use DNSSEC to get information out of DNS doesn't mean you can't use PKIX certificates during TLS negotiation with an application service. Peter -- Peter Saint-Andre https://stpeter.im/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424AF3A6984 for ; Wed, 18 Aug 2010 15:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW94bGP4NbZv for ; Wed, 18 Aug 2010 15:00:06 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 338533A6909 for ; Wed, 18 Aug 2010 15:00:05 -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 61C39C2AF; Wed, 18 Aug 2010 18:00:39 -0400 (EDT) Date: Wed, 18 Aug 2010 18:00:39 -0400 (EDT) From: Paul Wouters To: Peter Saint-Andre In-Reply-To: <4C6C52FA.3070207@stpeter.im> Message-ID: References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <20100818204352.GB94188@shinkuro.com> <4C6C52FA.3070207@stpeter.im> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 22:00:07 -0000 On Wed, 18 Aug 2010, Peter Saint-Andre wrote: >> Hear, hear. We don't need to debate whether one approach is better >> than the other. We're not writing signature-style-choices-bcp. The >> point is to write something that works interoperably provided that you >> accept the premise that what you want to use is DNSSEC. > > Which might mean using both DNSSEC and PKIX -- the choice is not either-or. I think previous attempts explicitely included PKIX, and the efforts died because of it. I was not at the IETF in Maastricht, so I did not attend the BOF, but I don't think commiting to a CA/X.509 will be very useful. the PKIX people will (again) say "we already have CA's for that". Perhaps some clarification could be made. Perhaps some container formats of PKIX might be used, but not the trust model of external CA's? (If you would do that, this would just become a repeat of RFC 4398) Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974613A6A1B for ; Wed, 18 Aug 2010 14:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.657 X-Spam-Level: X-Spam-Status: No, score=-102.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb01G8AwnfwW for ; Wed, 18 Aug 2010 14:38:36 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8B6E03A6A71 for ; Wed, 18 Aug 2010 14:38:34 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5CF5940074 for ; Wed, 18 Aug 2010 15:40:55 -0600 (MDT) Message-ID: <4C6C52FA.3070207@stpeter.im> Date: Wed, 18 Aug 2010 15:39:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: keyassure@ietf.org References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> <20100818204352.GB94188@shinkuro.com> In-Reply-To: <20100818204352.GB94188@shinkuro.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 21:38:39 -0000 On 8/18/10 2:43 PM, Andrew Sullivan wrote: > On Wed, Aug 18, 2010 at 04:18:25PM -0400, Paul Wouters wrote: >> But really, the discussion of whether I can trust a TLD operator more then >> a CA operator is outside the scope of this list. I believe what is desired >> here is a way to use the TLD operator without a CA operator. We already have >> the reverse case for those interested in that. > > Hear, hear. We don't need to debate whether one approach is better > than the other. We're not writing signature-style-choices-bcp. The > point is to write something that works interoperably provided that you > accept the premise that what you want to use is DNSSEC. Which might mean using both DNSSEC and PKIX -- the choice is not either-or. Peter -- Peter Saint-Andre https://stpeter.im/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2D73A6A40 for ; Wed, 18 Aug 2010 14:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.836 X-Spam-Level: X-Spam-Status: No, score=-0.836 tagged_above=-999 required=5 tests=[AWL=1.763, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCz3qrZLkiFX for ; Wed, 18 Aug 2010 14:35:22 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 662043A6A86 for ; Wed, 18 Aug 2010 14:35:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=WRhJH7m5XbTd+YHkg6o27ncgMIs87FXtuvWRL3eWjx6tnusaW4bQ10LM/A6h/n6b; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OlqIb-0003PN-Iq; Wed, 18 Aug 2010 17:35:53 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 18 Aug 2010 17:35:53 -0400 Message-ID: <15874910.1282167353578.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Wed, 18 Aug 2010 16:35:53 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Phillip Hallam-Baker , keyassure@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688c67dfce0477ebf8da166ddb993d16ecb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 21:35:24 -0000 Phillip and all, -----Original Message----- >From: Phillip Hallam-Baker >Sent: Aug 18, 2010 2:08 PM >To: keyassure@ietf.org >Subject: Re: [keyassure] Thanks for starting this - my wishlist :) > >I agree with what Andrew is saying here. But this is a discussion that >is in-charter for DNSEXT. > >Basically I am seeing people looking at DNSCURVE for last hop and >there are certainly many people doing IPSEC. As a security specialist, >I know that there are security capabilities I can provide in that >model that are not possible through endpoint security alone. > >My view is that where the validation takes place is for applications >and users to decide. It may even make sense to have no validation at >all. I have argued for years that Web Browsers should not provide a >warning when a site offers a self-signed cert, the browser should >simply turn on the crypto and not tell the user about it at all. If >the web browser will take the user to a site without any crypto >without a warning it should accept imperfect crypto on the same basis. In part I agree here. However not telling the user of the use of a cert, self-signed or not is not a good thing. Indeed though there is not such thing as 'perfict' crypto so accepting any of same is or should be a user choice. > >In the medium term, neither IPSEC or DNSCURVE (or SSL) are ideal for >this purpose. We can do better, but I won't elaborate the reasons why >here. Agreed strongly here as well... > > >On Wed, Aug 18, 2010 at 2:06 PM, Andrew Sullivan wrote: >> On Wed, Aug 18, 2010 at 10:34:08AM -0700, Nicholas Weaver wrote: >> >>> NOTHING I said implied that the application does the validating, >> >> Well, there were two ways I found to interpret your argument, and the >> other one seemed to me to be the well-worn arguments about why >> offloading to an upstream validator was a Bad Idea. =C2=A0I didn't figur= e >> you'd be hauling that argument to this list from another one, but I >> guess I was wrong. =C2=A0In the enterprise situation, we _have_ an >> implementer who is using the AD bit and IPSEC for the last hop. =C2=A0Yo= u >> keep insisting that's a dangerous model, but in the enterprise >> environment it isn't necessarily (and arguing from home-user-to-ISP >> analogies is simply irrelevant). >> >> The trouble in the case of the AD bit is that it's too little >> information. =C2=A0But we don't get to dismiss that use case just becaus= e >> we're currently not sure how to answer the query. =C2=A0And we might hav= e >> an opportunity here to address such issues (I kinda doubt it, but >> maybe). >> >>> to do the validating: the application NEEDS to tell the host to >>> validate and how to treat validation failures (because the default >>> will be wrong, no matter what the default is, unless the default is >> >> I think this is right. =C2=A0It sounds to me like an API issue. =C2=A0Th= e >> present one is likely the wrong list for that, though. =C2=A0I wish I kn= ew >> what to suggest apart from dnssec-deployment. >> >>> And that using such an API for validating A records is useless, >>> since any application thats smart enough to bother asking "is this A >>> record validated" is smart enough to realize that the A record >>> validation is meaningless [1]: a corrupted A record is just simply >>> one of many possible MitM attacks, so focus on blocking MitM >>> attacks, not A records: from an application viewpoint, there is no >>> difference between a poisoned DNS entry, a poisoned ARP cache, BGP >>> games, or a WiFi packet injector: a MitM is a MitM. >> >> So your argument is that if the DNSSEC validation comes back correct, >> we still aren't sure routing hasn't been compromised, so this is all >> useless? =C2=A0Surely that's wrong. =C2=A0Another way to do this would b= e to >> offload the validation to a trusted DNS server and offload similar >> validation for BGP &c. to something else, no? =C2=A0I don't really want = my >> phone doing hundreds of DNSSEC validation calculations for every >> cnn.com page view, do I? >> >>> And, frankly speaking, the "benefits" from DNSSEC only come when the >>> application is aware of DNSSEC >> >> I happen to think it is an advantage if I push validation to some >> layer (or system) I don't have to worry too much about, and then >> simply get a failure when someone is spoofing the DNS answer. =C2=A0I >> cheerfully concede it's not a complete solution to every possible >> problem; but if I were interested in solving world peace and hunger, >> I'd be a diplomat or a missionary rather than a geek. =C2=A0You appear t= o >> be arguing that because DNSSEC validation successes do not prevent >> attacks on the routing infrastructur, therefore DNSSEC validation does >> no good. =C2=A0That strikes me as a hard position to maintain. >> >> >> -- >> Andrew Sullivan >> ajs@shinkuro.com >> Shinkuro, Inc. >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >> > > > >--=20 >Website: http://hallambaker.com/ >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, = strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liabilit= y depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.co= m Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B58F3A6A1D for ; Wed, 18 Aug 2010 14:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.675 X-Spam-Level: X-Spam-Status: No, score=-0.675 tagged_above=-999 required=5 tests=[AWL=1.924, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOEYA-LB8FIx for ; Wed, 18 Aug 2010 14:24:16 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id ADDA33A6A08 for ; Wed, 18 Aug 2010 14:24:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=OHlUXlRl1NgrpoLAncJtHtKHZCtJ4/he9ze5kGxn0bOk1/2lhNpg6iOoWhgS9vcI; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Olq7t-0002KL-AY; Wed, 18 Aug 2010 17:24:49 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 18 Aug 2010 17:24:49 -0400 Message-ID: <29260948.1282166689320.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Wed, 18 Aug 2010 16:24:49 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Phillip Hallam-Baker , Andrew Sullivan Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068814a0fc4fe79866fa92cd33109ef91bae350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 Cc: william.barker@nist.gov, keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 21:24:20 -0000 Phillip and all, FWIW, I am not sure I would trust a cert signed by Verisign right now given that recently their=20 Cert database was hacked/breached and I have no independant assurance that Verisign has 'fixed' that breach adaquately and/or informed 'All' of its Cert customers accordingly. None the less, Verisign produces good Certs, so the question than becomes=20 is the user of that Cert now the correct one and how does anyone know that for sure? -----Original Message----- >From: Phillip Hallam-Baker >Sent: Aug 18, 2010 2:55 PM >To: Andrew Sullivan >Cc: keyassure@ietf.org >Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in application= s > >On Wed, Aug 18, 2010 at 12:39 PM, Andrew Sullivan wrote= : >>> >>> 1 - DNSSEC can tell me who owns some DNS data, like an assertion about >>> a hostname. =C2=A0I don't think I know any more than that. =C2=A0That's= pretty >>> important, but >>> >>> 2 - X.509 certificates could tell me a lot more about what I can expect >>> from the transaction I am starting. =C2=A0It can deliver a level of ass= urance >>> attribute, a policy pointer of some kind that can lead to a complete >>> disclosure of what this certificate means, and other attributes that >>> describe what this certificate is supposed to permit or deny. =C2=A0I d= on't >>> think this is available in DNSSEC. =C2=A0We can argue about the utility= of >>> some of this but that's not the issue. >>> >>> Another way of looking at it - this should be up the stack & closer to >>> the application's viewpoint than DNS is (should be). =C2=A0So perhaps >> >> It seems to me that this distinction is one on which we foundered >> during the BOF, too. >> >> There are two completely different use cases for TLS, and we will get >> nowhere if we assert that solutions for one are inadequate solutions >> for the other. >> >> The goal in the current keys-linkage draft, as I read it, is simply to >> gain some assurance that the PKIX cert in question is actually >> associated with the domain it claims to be. =C2=A0That is by no means an= y >> kind of assurance that (say) the domain is actually operated by the >> organization one thinks it is (i.e. it doesn't prove that >> www.mybank.com is actually operated by My Bank, member FDIC). > >With DNSSEC alone we have a domain linkage, but no accountability for it. > >With DV we have a measure of accountability in that CAs that really >screw up could in theory be dumped out of the browsers and we have >defined and audited processes. > >With EV we have an industry standard assurance level and audited process. > >Now we could have a pointless discussion about whether DV is really >more secure than DNSSEC, but I think thats pointless as I don't think >anyone is willing to state that either is a sufficient basis for >handing over your credit card number or doing banking. And so neither >should merit a padlock icon. > > >> The first of those is not too far from your (1) (but I think your >> description doesn't quite capture the power of being able to guarantee >> you got the right result from the DNS). =C2=A0The second of these is >> plainly related to your (2). >> >> The fact is that many people think (2) is a waste of time for many >> purposes: many of the actual CAs simply don't do anything like the job >> necessary to believe their assertions about identity and so on >> embodied in the cert. =C2=A0Therefore, the "utility of some of this" is = not >> the issue directly, but it certainly is a motivating factor in the >> discussion. =C2=A0I don't think we can dismiss it. =C2=A0If the faciliti= es that >> are supposed to be offered by a technology don't work in practice, >> then the lack of utility is relevant to rhe duscussion. =C2=A0(This is n= ot >> to say the facilities are never useful. =C2=A0But as general >> infrastructure, they haven't worked out so well in terms of actually >> identifying complete strangers to one anhother.) > >One big problem here, one that I did insist we deal with in EV was to >actually show who is providing the certificate to the end user. A >green bar from a VeriSign or a Comodo may not mean the same to the end >user as a green bar from Bogocert CA they never heard of before. > >The importance of this distinction was just demonstrated in the UAE >case. Perhaps people are not going to want to trust CAs in certain >parts of the world for certain purposes. I would not accept code >signed with a cert from a Nigerian, Sudanese or Russian CA. > > > >--=20 >Website: http://hallambaker.com/ >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, = strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liabilit= y depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.co= m Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2978B3A6988 for ; Wed, 18 Aug 2010 14:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.787 X-Spam-Level: X-Spam-Status: No, score=0.787 tagged_above=-999 required=5 tests=[AWL=0.786, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDK2HWxUlhtw for ; Wed, 18 Aug 2010 14:03:52 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 340CF3A6A95 for ; Wed, 18 Aug 2010 14:03:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=Zh0I+ZacNUy+17TSaLFAf5RkJYUHWm8lwpxezxPlGf2MjjRGEkK9CHQuiOGLwmFE; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OlpoA-0003ax-DC; Wed, 18 Aug 2010 17:04:26 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 18 Aug 2010 17:04:25 -0400 Message-ID: <25804804.1282165466187.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Wed, 18 Aug 2010 16:04:25 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Andrew Sullivan , keyassure@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606889a743b5f8ebe592bf3b471f75f8234a7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 21:03:53 -0000 Andrew and all, Very much agreed! >:) -----Original Message----- >From: Andrew Sullivan >Sent: Aug 18, 2010 3:43 PM >To: keyassure@ietf.org >Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications > >On Wed, Aug 18, 2010 at 04:18:25PM -0400, Paul Wouters wrote: >> But really, the discussion of whether I can trust a TLD operator more then >> a CA operator is outside the scope of this list. I believe what is desired >> here is a way to use the TLD operator without a CA operator. We already have >> the reverse case for those interested in that. > >Hear, hear. We don't need to debate whether one approach is better >than the other. We're not writing signature-style-choices-bcp. The >point is to write something that works interoperably provided that you >accept the premise that what you want to use is DNSSEC. > >A > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 294k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6BF3A6A71 for ; Wed, 18 Aug 2010 13:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.724 X-Spam-Level: X-Spam-Status: No, score=-101.724 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXV3Dv580xec for ; Wed, 18 Aug 2010 13:43:19 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A08853A6405 for ; Wed, 18 Aug 2010 13:43:19 -0700 (PDT) Received: from crankycanuck.ca (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 3EEFB1ECB408 for ; Wed, 18 Aug 2010 20:43:54 +0000 (UTC) Date: Wed, 18 Aug 2010 16:43:52 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20100818204352.GB94188@shinkuro.com> References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:43:22 -0000 On Wed, Aug 18, 2010 at 04:18:25PM -0400, Paul Wouters wrote: > But really, the discussion of whether I can trust a TLD operator more then > a CA operator is outside the scope of this list. I believe what is desired > here is a way to use the TLD operator without a CA operator. We already have > the reverse case for those interested in that. Hear, hear. We don't need to debate whether one approach is better than the other. We're not writing signature-style-choices-bcp. The point is to write something that works interoperably provided that you accept the premise that what you want to use is DNSSEC. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360133A6949 for ; Wed, 18 Aug 2010 13:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.869 X-Spam-Level: X-Spam-Status: No, score=-99.869 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wu3Fke0NN0yG for ; Wed, 18 Aug 2010 13:32:28 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 437433A67FB for ; Wed, 18 Aug 2010 13:32:28 -0700 (PDT) Received: from [10.20.30.158] (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 o7IKX0rs011618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Aug 2010 13:33:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> Date: Wed, 18 Aug 2010 13:32:53 -0700 To: Phillip Hallam-Baker , Andrew Sullivan From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:32:30 -0000 At 3:55 PM -0400 8/18/10, Phillip Hallam-Baker wrote: >With DNSSEC alone we have a domain linkage, but no accountability for it. This is completely incorrect. The accountability is to "the same person who gave you the A record that you are about to use to go to the site". --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA60F3A68F2 for ; Wed, 18 Aug 2010 13:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sf6zMhGmmLZ5 for ; Wed, 18 Aug 2010 13:17:51 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id BBB4B3A6846 for ; Wed, 18 Aug 2010 13:17:51 -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 A7598BC07; Wed, 18 Aug 2010 16:18:25 -0400 (EDT) Date: Wed, 18 Aug 2010 16:18:25 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:17:52 -0000 On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote: > With DNSSEC alone we have a domain linkage, but no accountability for it. There is a path of accountability. > With EV we have an industry standard assurance level and audited process. EV only works because I cannot get it for $15. The internet is more then just a few wealthy corporations that can afford to join an elite club. > The importance of this distinction was just demonstrated in the UAE > case. Perhaps people are not going to want to trust CAs in certain > parts of the world for certain purposes. I would not accept code > signed with a cert from a Nigerian, Sudanese or Russian CA. Nor RealTek. or Microsoft. To name two compromised pieces of signed code. But really, the discussion of whether I can trust a TLD operator more then a CA operator is outside the scope of this list. I believe what is desired here is a way to use the TLD operator without a CA operator. We already have the reverse case for those interested in that. Provided we use the security features DNSSEC offers us, how can we best implement new record types to satisfy the needs of a variety of uses by a variety of applications. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7FD03A6AAF for ; Wed, 18 Aug 2010 12:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h142otr88qBQ for ; Wed, 18 Aug 2010 12:55:10 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D55293A6AA7 for ; Wed, 18 Aug 2010 12:55:09 -0700 (PDT) Received: by iwn3 with SMTP id 3so1028896iwn.31 for ; Wed, 18 Aug 2010 12:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SIRFy/w7m+bCdxgOy5k/+DXTPJdG/ABt6GM5i1r1Ask=; b=aMD9RZy3yQyUHcnyKfFNl8b9sLmvLI1txEvQCqB0+1SBLjH86O93ryWGmGzgYX2CZw nKiHPE2AT5LSOz0m5FXLZTWmS3jLvCu1c0OI101g3GHh2GTtLMmf1n27oOoeR9BCQnZl b67ckGkI9yhMY/Z3lI7AAtQ5PiP8wzaFMNxvg= 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:content-transfer-encoding; b=WDSvbLCEcqms1/EzBSWWEZJoYIXS556phLsHUp6bUlVZsluRbY+5KCjhGOJ5nXJHan VTJIBKcDBrxNzChcCLhR8CT1jbgnmd1gnPDxHjtbEHd0+MvSfefxOQsF/ybuLH04o/9Z 7N7j/IE4kSs0GectWXSDUJ/s4pdn/RtIf84NU= MIME-Version: 1.0 Received: by 10.231.39.195 with SMTP id h3mr9643509ibe.88.1282161344597; Wed, 18 Aug 2010 12:55:44 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Wed, 18 Aug 2010 12:55:44 -0700 (PDT) In-Reply-To: <20100818163921.GG92904@shinkuro.com> References: <201008181611.o7IGBeQQ009528@fionn.es.net> <20100818163921.GG92904@shinkuro.com> Date: Wed, 18 Aug 2010 15:55:44 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:55:12 -0000 On Wed, Aug 18, 2010 at 12:39 PM, Andrew Sullivan wrote: >> >> 1 - DNSSEC can tell me who owns some DNS data, like an assertion about >> a hostname. =A0I don't think I know any more than that. =A0That's pretty >> important, but >> >> 2 - X.509 certificates could tell me a lot more about what I can expect >> from the transaction I am starting. =A0It can deliver a level of assuran= ce >> attribute, a policy pointer of some kind that can lead to a complete >> disclosure of what this certificate means, and other attributes that >> describe what this certificate is supposed to permit or deny. =A0I don't >> think this is available in DNSSEC. =A0We can argue about the utility of >> some of this but that's not the issue. >> >> Another way of looking at it - this should be up the stack & closer to >> the application's viewpoint than DNS is (should be). =A0So perhaps > > It seems to me that this distinction is one on which we foundered > during the BOF, too. > > There are two completely different use cases for TLS, and we will get > nowhere if we assert that solutions for one are inadequate solutions > for the other. > > The goal in the current keys-linkage draft, as I read it, is simply to > gain some assurance that the PKIX cert in question is actually > associated with the domain it claims to be. =A0That is by no means any > kind of assurance that (say) the domain is actually operated by the > organization one thinks it is (i.e. it doesn't prove that > www.mybank.com is actually operated by My Bank, member FDIC). With DNSSEC alone we have a domain linkage, but no accountability for it. With DV we have a measure of accountability in that CAs that really screw up could in theory be dumped out of the browsers and we have defined and audited processes. With EV we have an industry standard assurance level and audited process. Now we could have a pointless discussion about whether DV is really more secure than DNSSEC, but I think thats pointless as I don't think anyone is willing to state that either is a sufficient basis for handing over your credit card number or doing banking. And so neither should merit a padlock icon. > The first of those is not too far from your (1) (but I think your > description doesn't quite capture the power of being able to guarantee > you got the right result from the DNS). =A0The second of these is > plainly related to your (2). > > The fact is that many people think (2) is a waste of time for many > purposes: many of the actual CAs simply don't do anything like the job > necessary to believe their assertions about identity and so on > embodied in the cert. =A0Therefore, the "utility of some of this" is not > the issue directly, but it certainly is a motivating factor in the > discussion. =A0I don't think we can dismiss it. =A0If the facilities that > are supposed to be offered by a technology don't work in practice, > then the lack of utility is relevant to rhe duscussion. =A0(This is not > to say the facilities are never useful. =A0But as general > infrastructure, they haven't worked out so well in terms of actually > identifying complete strangers to one anhother.) One big problem here, one that I did insist we deal with in EV was to actually show who is providing the certificate to the end user. A green bar from a VeriSign or a Comodo may not mean the same to the end user as a green bar from Bogocert CA they never heard of before. The importance of this distinction was just demonstrated in the UAE case. Perhaps people are not going to want to trust CAs in certain parts of the world for certain purposes. I would not accept code signed with a cert from a Nigerian, Sudanese or Russian CA. --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7AC63A6A81 for ; Wed, 18 Aug 2010 12:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZUnyyKMZDMg for ; Wed, 18 Aug 2010 12:38:14 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id BEC4D3A6A20 for ; Wed, 18 Aug 2010 12:38:11 -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 52EBCBC07; Wed, 18 Aug 2010 15:38:45 -0400 (EDT) Date: Wed, 18 Aug 2010 15:38:45 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:38:18 -0000 X-List-Received-Date: Wed, 18 Aug 2010 19:38:18 -0000 On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote: > In my view user keys do not belong in the DNS because the DNS is > an infrastructure for locating network services, not network users. I disagree. You are locating an identity. Currently, that is mostly done based on an IP address and port. I'd hope tomorrow that would mostly be done based on a public key or hash. Especially with mobile devices, IP's are very volatile. To locate a service or user, we need the DNS. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260AE3A6A76 for ; Wed, 18 Aug 2010 12:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEaz8Uw2L12l for ; Wed, 18 Aug 2010 12:20:09 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id DCE013A6A80 for ; Wed, 18 Aug 2010 12:20:08 -0700 (PDT) Received: by pvg7 with SMTP id 7so410032pvg.31 for ; Wed, 18 Aug 2010 12:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=0CIqzzXrLBnGkePkQn8D1ZQn4+AdWlTkqOrvqHxBWIA=; b=qlX2+OGb5s/jI3d64mNQwBTkQucJDYSzPYpTQEihfMgxrw4lcw1kSJ5iRLkqVLuC3y vKcMdh0Ce4zTkwT0onSZwv2durQCliwLSeC4LUom0374f/rqOjeoxG4+JjkOq2lZmy2p CAhFzXXD8N6w2CgQA2XZtvt/cHbKiCAleD0b4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=uPwCR1mwWLosxBQKSyhcKtUFn79kCBtNWjPSiek6E4mYUqF1hXaAgofZO4VkkC49Pe iztCSze16iVc3idLk6rgbAIJ8DoDuieGNClBgy0yR6duSoAi6XPsXuW2NB304qW5Dy6O gcKgHM0VNlEVWY1tCaKkG1kVnDM6C6Y3siqwQ= Received: by 10.114.58.11 with SMTP id g11mr10106812waa.14.1282159244105; Wed, 18 Aug 2010 12:20:44 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id d38sm1023882wam.20.2010.08.18.12.20.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 12:20:42 -0700 (PDT) Sender: Nicholas Weaver References: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> <20100818171331.GI92904@shinkuro.com> <20100818180628.GK92904@shinkuro.com> <20100818190640.GN92904@shinkuro.com> In-Reply-To: <20100818190640.GN92904@shinkuro.com> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <1DFBADBE-1789-43EF-8FE6-ED1139170070@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 18 Aug 2010 12:20:41 -0700 To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:20:12 -0000 On Aug 18, 2010, at 12:06 PM, Andrew Sullivan wrote: > On Wed, Aug 18, 2010 at 11:37:11AM -0700, Nicholas Weaver wrote: >> EG, how many times is it WRONG to say "sure, I'll accept the self = signed cert" in web browsing? >>=20 >=20 > If you don't think that's a problem, then why do this work? (That is, > dope that I am, I don't even understand why you think this debate is > worth joining if you think the whole thing a non-problem.) My attitude towards DNSSEC is exactly why I think THIS group is = valuable. =20 DNSSEC for DNSSEC's sake is already happening thanks to various = mandates, even if, for securing Name->Address mappings, it is a combined = world of hurt and useless. =20 But if this world is going to exist, I believe we should extract = something very VERY useful out of that, which is using DNSSEC for = Name->Key material mappings (or other data that is consumed directly by = the client rather than simply being used to contact a remote host.) Since I think DNSSEC is incredibly valuable for securing Name->Key = Material mappings: providing, for nearly-free, certificates which flow = along already existing trust relationships, and without the = proliferating root of trust problems existing in SSL, the price gouging = which exists in SSL for wildcard certs, or the leap-of-faith problems = present in ssh, I think its very important to make sure that we actually = have a good way of doing this. Since this group is about developing ways to make sure that Name->Key = Material bindings can happen and are useful, this group is exactly where = I believe the emphasis should be. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E5B3A6A70 for ; Wed, 18 Aug 2010 12:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=0.791, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0udZVtSMcvM for ; Wed, 18 Aug 2010 12:08:15 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id C75263A680D for ; Wed, 18 Aug 2010 12:08:14 -0700 (PDT) Received: by gyg8 with SMTP id 8so403135gyg.31 for ; Wed, 18 Aug 2010 12:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=WAif9AL/BK9ThBzTezUocahNhzioa0wYxij5DhwbXNM=; b=K5fo2DZph7ZTzIff6wbxjE5cvvoNRIzx37303lkPhgAtTApLidcCfOO2LgPT697yxJ z/ur7UwNOtEfNqCPIUXzsPGQ/q/pDBfoDwd3TiJoC1g6pM8w0xTzigQ6sTpgXYlBj7Az ZdIRPFjK9sbiGJCNkVymfAJYyRqy98vmSji80= 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 :content-type:content-transfer-encoding; b=lT9TJ2fMSElX417IbvQs9+twahTTHYsRg5+2frI/2s5EJG6UDSjFBgvGcQWOmU6NIt fKcBRoekBGVPGkM9X7Qc3WBballlJzlx7HH9fmk6fnDIGr/uKxn/x/duFChjUw103Z5X 79VZ/pG91Rvhj0cDX+bibcq5F+ki1QNP5lK2w= MIME-Version: 1.0 Received: by 10.100.108.8 with SMTP id g8mr9937645anc.174.1282158529611; Wed, 18 Aug 2010 12:08:49 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Wed, 18 Aug 2010 12:08:49 -0700 (PDT) In-Reply-To: <20100818180628.GK92904@shinkuro.com> References: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> <20100818171331.GI92904@shinkuro.com> <20100818180628.GK92904@shinkuro.com> Date: Wed, 18 Aug 2010 15:08:49 -0400 Message-ID: From: Phillip Hallam-Baker To: keyassure@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:08:16 -0000 I agree with what Andrew is saying here. But this is a discussion that is in-charter for DNSEXT. Basically I am seeing people looking at DNSCURVE for last hop and there are certainly many people doing IPSEC. As a security specialist, I know that there are security capabilities I can provide in that model that are not possible through endpoint security alone. My view is that where the validation takes place is for applications and users to decide. It may even make sense to have no validation at all. I have argued for years that Web Browsers should not provide a warning when a site offers a self-signed cert, the browser should simply turn on the crypto and not tell the user about it at all. If the web browser will take the user to a site without any crypto without a warning it should accept imperfect crypto on the same basis. In the medium term, neither IPSEC or DNSCURVE (or SSL) are ideal for this purpose. We can do better, but I won't elaborate the reasons why here. On Wed, Aug 18, 2010 at 2:06 PM, Andrew Sullivan wrote: > On Wed, Aug 18, 2010 at 10:34:08AM -0700, Nicholas Weaver wrote: > >> NOTHING I said implied that the application does the validating, > > Well, there were two ways I found to interpret your argument, and the > other one seemed to me to be the well-worn arguments about why > offloading to an upstream validator was a Bad Idea. =A0I didn't figure > you'd be hauling that argument to this list from another one, but I > guess I was wrong. =A0In the enterprise situation, we _have_ an > implementer who is using the AD bit and IPSEC for the last hop. =A0You > keep insisting that's a dangerous model, but in the enterprise > environment it isn't necessarily (and arguing from home-user-to-ISP > analogies is simply irrelevant). > > The trouble in the case of the AD bit is that it's too little > information. =A0But we don't get to dismiss that use case just because > we're currently not sure how to answer the query. =A0And we might have > an opportunity here to address such issues (I kinda doubt it, but > maybe). > >> to do the validating: the application NEEDS to tell the host to >> validate and how to treat validation failures (because the default >> will be wrong, no matter what the default is, unless the default is > > I think this is right. =A0It sounds to me like an API issue. =A0The > present one is likely the wrong list for that, though. =A0I wish I knew > what to suggest apart from dnssec-deployment. > >> And that using such an API for validating A records is useless, >> since any application thats smart enough to bother asking "is this A >> record validated" is smart enough to realize that the A record >> validation is meaningless [1]: a corrupted A record is just simply >> one of many possible MitM attacks, so focus on blocking MitM >> attacks, not A records: from an application viewpoint, there is no >> difference between a poisoned DNS entry, a poisoned ARP cache, BGP >> games, or a WiFi packet injector: a MitM is a MitM. > > So your argument is that if the DNSSEC validation comes back correct, > we still aren't sure routing hasn't been compromised, so this is all > useless? =A0Surely that's wrong. =A0Another way to do this would be to > offload the validation to a trusted DNS server and offload similar > validation for BGP &c. to something else, no? =A0I don't really want my > phone doing hundreds of DNSSEC validation calculations for every > cnn.com page view, do I? > >> And, frankly speaking, the "benefits" from DNSSEC only come when the >> application is aware of DNSSEC > > I happen to think it is an advantage if I push validation to some > layer (or system) I don't have to worry too much about, and then > simply get a failure when someone is spoofing the DNS answer. =A0I > cheerfully concede it's not a complete solution to every possible > problem; but if I were interested in solving world peace and hunger, > I'd be a diplomat or a missionary rather than a geek. =A0You appear to > be arguing that because DNSSEC validation successes do not prevent > attacks on the routing infrastructur, therefore DNSSEC validation does > no good. =A0That strikes me as a hard position to maintain. > > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD533A687B for ; Wed, 18 Aug 2010 12:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hsSsB3HAKke for ; Wed, 18 Aug 2010 12:07:02 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 596113A680D for ; Wed, 18 Aug 2010 12:07:02 -0700 (PDT) Received: by pxi6 with SMTP id 6so410787pxi.31 for ; Wed, 18 Aug 2010 12:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=Rs7PpxB/sLMX5EhqNnhPPgbh8/or3D0dkRICLylQ3K8=; b=O+j0rKEAzlHgVY5vo6u7wmeX5+qF6mnmA8nsG/TKLeChKAPL/C0eBjKuYvxRHZa32i qRo8IisFzloUDnsu0qs0/C+3jUNRVzLU9wbCtdTtCC5HBh86FjCyiqtOfstRbYP/EIF+ nV4mOedLTx92f51CONF0ne1VWMfHtPGww03SM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=s4aAI3DHzBbQiAbnjit4VVUnITnahn0pUWPACYGT9mpPGeDqmZ19yGXyw0PRiSD3CX G42Mz1b6OKREEZSp+otZLh71HhqCQf6376jk4Uw6EnZ16raJhVAFck7dys2KWZR4yiDh qcqWG/aZ13W5xRvW9ApWa5QSFLScTGRtCt0E0= Received: by 10.114.130.20 with SMTP id c20mr10054758wad.104.1282158457546; Wed, 18 Aug 2010 12:07:37 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id d35sm1001078waa.21.2010.08.18.12.07.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 12:07:36 -0700 (PDT) Sender: Nicholas Weaver References: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <148D44CB-80A1-4135-A1A1-30F99F77357E@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 18 Aug 2010 12:07:34 -0700 To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, Nicholas Weaver Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:07:03 -0000 On Aug 18, 2010, at 12:02 PM, Phillip Hallam-Baker wrote: > I don't think either works. >=20 > We should be encouraging people to use a separate private key for each > physical host. So we certainly should not be creating specs that make > it hard to do that. I'm not so sure about this. So much of the Internet relies on LOGICAL = host, being defined by hostname rather than IP, that separate key for = logical host is what is done today, so it actually does fit well with = DNSSEC. Otherwise, if you want to store material on a physical host (approx by = IP), you need to first get the logical host list and then do a reverse = DNS lookup on the IP to get the key material. But I can see that being worth supporting too: so you do a query for = both keymaterial for hostname keymaterial for IP and use the union of those two sets as the key material for the host you = are commuinacting with. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902C33A680D for ; Wed, 18 Aug 2010 12:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSpfywZXodxd for ; Wed, 18 Aug 2010 12:06:07 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 8F3AE3A687B for ; Wed, 18 Aug 2010 12:06:07 -0700 (PDT) Received: from crankycanuck.ca (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 F41701ECB408 for ; Wed, 18 Aug 2010 19:06:41 +0000 (UTC) Date: Wed, 18 Aug 2010 15:06:40 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20100818190640.GN92904@shinkuro.com> Mail-Followup-To: keyassure@ietf.org References: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> <20100818171331.GI92904@shinkuro.com> <20100818180628.GK92904@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:06:08 -0000 On Wed, Aug 18, 2010 at 11:37:11AM -0700, Nicholas Weaver wrote: > EG, how many times is it WRONG to say "sure, I'll accept the self signed cert" in web browsing? > If you don't think that's a problem, then why do this work? (That is, dope that I am, I don't even understand why you think this debate is worth joining if you think the whole thing a non-problem.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F7AA3A6984 for ; Wed, 18 Aug 2010 12:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWZGys2Bf6-C for ; Wed, 18 Aug 2010 12:02:06 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E37233A6A72 for ; Wed, 18 Aug 2010 12:01:51 -0700 (PDT) Received: by iwn3 with SMTP id 3so986441iwn.31 for ; Wed, 18 Aug 2010 12:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sPKX3r9lTHnPjzN+H/HZDKocIIV3sGjDYK7PtkTp1vw=; b=yGW5bzHB89VacywLyzuP9omfIXFFXNwlTz74oEYA1NJhbFqM3ksPousfx6ZRo+CZsN WnfUOylprbHvFvJeLMxm7EDsvCNYDfAVWa2OV4flVn/d0KpyYr7EkT5Pm9DI7UNQiF+t etk0Jj05pt9pR4gevIO+uJPs8QZATBkn2W2Ag= 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:content-transfer-encoding; b=gNPFVbhWtmYAuHGfrmgXEZpcH8pzcGnz9tYGiGA307ex4amAjCjmIDlZ10pn0zRtGz Xxm+MDG4ZUMCBTbs+PcHXOrJIHWzeVccOy8nFFiLteLMm9mTKfykc75ro/NP6CGC+3qr zKLsvawnD00VDYPr0NRSj8q0hmq/lpC7+FAms= MIME-Version: 1.0 Received: by 10.231.30.134 with SMTP id u6mr9830067ibc.121.1282158146961; Wed, 18 Aug 2010 12:02:26 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Wed, 18 Aug 2010 12:02:26 -0700 (PDT) In-Reply-To: References: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> Date: Wed, 18 Aug 2010 15:02:26 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:02:07 -0000 I don't think either works. We should be encouraging people to use a separate private key for each physical host. So we certainly should not be creating specs that make it hard to do that. In the case of SSL the relying application has the certificate in hand at the start of the validation process. It is thus possible to put an attribute in the cert to say 'hey I have a DNS key chain' and to give a prefix that can be used for distinguishing between certs. There are two separate issues here 1) Validating keys 2) Determining what the security criteria are for a given app. I would prefer to use the CERTHASH record I proposed in the other post to do the first and separate out the second into a per-protocol security options record that gives security related info. For example _smtp._tcp.example.com OPTION "SSL=3DOFFERED KEYSERVER=3DLDAP,XKMS" _submit._tcp.example.com OPTION "SSL=3DREQUIRED AUTH=3DREQUIRED" _http._tcp.example.com OPTION "SSL=3DALWAYS SRV=3DTRUE AUTH=3DYAFAP" I see the elements in an OPTION record as being protocol specific. There would have to be a draft written for each protocol to say what the interpretation of the code points would be for that particular protocol. For some limited protocols, possibly only SSH and like protocols that typically bind to specific hosts rather than abstract services, it might even make sense to put the raw SSH key into an OPTION record. But I see that as a special case, rather than the norm. Note that for SMTP I specify two methods of obtaining user certs for sending an encrypted message. This is where I see user keys coming from. In my view user keys do not belong in the DNS because the DNS is an infrastructure for locating network services, not network users. It is of course the infrastructure that we use to locate the infrastructure for locating users however. On Wed, Aug 18, 2010 at 1:25 PM, Paul Wouters wrote: > On Wed, 18 Aug 2010, Nicholas Weaver wrote: > >>> 1) Key packaging (eg using raw keys or using certificates or using usag= e >>> bits) >> >> Or hashes of keys. =A0This would be my vote, as a hash allows > > Yes, hashes is what i meant with "raw key", sorry. > >>> 2) Try to make a new DNS record that can be used by more then just one >>> =A0application (eg not SSHFP) to avoid spamming the apex. >>> 3) Try to make the new DNS record specific enough that we can request >>> specific >>> =A0ones (eg I need the key for TLS over SMTP, not the ipsec or ssh key) >> >> Hmm, this would require some sort of subdomain scheme then, eg >> KEYMATERIAL ssl.www.mydomain.com -> RR for SSL key >> KEYMATERIAL ssh.www.mydomain.com -> RR for ssh key > > We could have sub typing instead. That would avoid ugly name space collis= on, > eg if > I have a server named ssl.mydomain.com. > >> Does that really make things better vs >> KEYMATERIAL www.mydomain.com -> {ssl-fingerprint: X, ssh-fingerprint: Y}= ?? > > that could get big with 10 different apps on a server? > >>> 6) Think about application requests, eg "I only want the A record when = it >>> was >>> =A0DNSSEC validated" >> >> You example of this is worse than useless. =A0Any application smart enou= gh >> to ask that question should be smart enough to not need to trust the ans= wer. > > The example was bad because it is actually covered by the AD bit, yes. > Let's say "I only want the A record when you can get data through an > anonymizer" We currently can only ask for "passed validation", which is > limiting. > > Paul > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7103A6A1B for ; Wed, 18 Aug 2010 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.944, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUGO2FgFEFq0 for ; Wed, 18 Aug 2010 11:36:46 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 95A3E3A686E for ; Wed, 18 Aug 2010 11:36:42 -0700 (PDT) Received: by yxk8 with SMTP id 8so374132yxk.31 for ; Wed, 18 Aug 2010 11:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=70Njg+4xSqdkMx3B7tQgCUHMJ+abPjCysxprqSBdIuk=; b=TiSClUFEQncHEfy8NCJ1r3rb1q7pAj4FrlZPlFISIhzOMKpsEW8WL5m6c5fI0v0BID rucrzCjDm7U1i+xbOXrEn9FTctfkwxlssYVEwQunSnAOw7xN8IZ3ssRBPHbN0KAS3zaB gvau4Va3XUuu6mjjemdXdBC2Xa/x23BFGEv1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=P1F6oJoOSinOintkqszqKn2IutPAfC9AJkSxjlIiYKOXa53ELstj7qXR2TtZ9xwLvG JXw0ojP+3RwQDXSx6i+532yWxBfsxA6ecfTzEUjkd0AUVb3opKl3Ft13gIy+2fwd67Q7 glhCmLebRayxx2c+1Tyc2IhvkCvvLlhJQh4KY= Received: by 10.101.127.5 with SMTP id e5mr9834366ann.138.1282156637309; Wed, 18 Aug 2010 11:37:17 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id h5sm830067anb.8.2010.08.18.11.37.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 11:37:14 -0700 (PDT) Sender: Nicholas Weaver References: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> <20100818171331.GI92904@shinkuro.com> <20100818180628.GK92904@shinkuro.com> In-Reply-To: <20100818180628.GK92904@shinkuro.com> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 18 Aug 2010 11:37:11 -0700 To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 18:36:48 -0000 On Aug 18, 2010, at 11:06 AM, Andrew Sullivan wrote: >> And that using such an API for validating A records is useless, >> since any application thats smart enough to bother asking "is this A >> record validated" is smart enough to realize that the A record >> validation is meaningless [1]: a corrupted A record is just simply >> one of many possible MitM attacks, so focus on blocking MitM >> attacks, not A records: from an application viewpoint, there is no >> difference between a poisoned DNS entry, a poisoned ARP cache, BGP >> games, or a WiFi packet injector: a MitM is a MitM. >=20 > So your argument is that if the DNSSEC validation comes back correct, > we still aren't sure routing hasn't been compromised, so this is all > useless? Surely that's wrong. Another way to do this would be to > offload the validation to a trusted DNS server and offload similar > validation for BGP &c. to something else, no? I don't really want my > phone doing hundreds of DNSSEC validation calculations for every > cnn.com page view, do I? You're missing the point: Against a man in the middle, it doesn't = matter HOW they became a MitM, what matters is using end-to-end = cryptography in the application/transport to prevent the MitM from doing = any damage. You don't try to block packet-injection based DNS forging, BGP forging, = ARP poisoning, DHCP poisoning, WiFi packet injection, and the whole rest = of the laundry list. Its huge, and some can't be prevented without = changing the layer 1/2 network completely. Instead, you build the system to resist a MitM and don't worry how the = attacker became a MitM. And this is why I don't consider DNSSEC to secure DNS A records against = a MitM productive, or validating on the not-the-end-host resolver: it = only matters when the DNS MitM wouldn't be on the final application path = MitM, which IS pretty much just the not-the-end-host resolver. >> And, frankly speaking, the "benefits" from DNSSEC only come when the >> application is aware of DNSSEC >=20 > I happen to think it is an advantage if I push validation to some > layer (or system) I don't have to worry too much about, and then > simply get a failure when someone is spoofing the DNS answer. I > cheerfully concede it's not a complete solution to every possible > problem; but if I were interested in solving world peace and hunger, > I'd be a diplomat or a missionary rather than a geek. You appear to > be arguing that because DNSSEC validation successes do not prevent > attacks on the routing infrastructur, therefore DNSSEC validation does > no good. That strikes me as a hard position to maintain. Except that this system, if not on the final end host IS both the = adversary, and 99.9% (being charitable here, probably 100%) of the = 'spoofing' detected by this system will not be spoofing, but someone = messing up the key handling. EG, how many times is it WRONG to say "sure, I'll accept the self signed = cert" in web browsing? Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA283A68A5 for ; Wed, 18 Aug 2010 11:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.617 X-Spam-Level: X-Spam-Status: No, score=-4.617 tagged_above=-999 required=5 tests=[AWL=1.983, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPqpRWdF5qUx for ; Wed, 18 Aug 2010 11:23:29 -0700 (PDT) Received: from relay002.lsu.edu (relay002.lsu.edu [130.39.6.157]) by core3.amsl.com (Postfix) with ESMTP id 70C513A686E for ; Wed, 18 Aug 2010 11:23:29 -0700 (PDT) Received: from lsu.edu (nir-stealth.lsu.edu [130.39.193.41]) (authenticated bits=0) by relay002.lsu.edu (8.13.8/8.13.8) with ESMTP id o7IIO1PE014558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Aug 2010 13:24:01 -0500 Date: Wed, 18 Aug 2010 13:24:01 -0500 From: Anthony Iliopoulos To: keyassure@ietf.org Message-ID: <20100818182401.GC22159@lsu.edu> References: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> <20100818171331.GI92904@shinkuro.com> <20100818180628.GK92904@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100818180628.GK92904@shinkuro.com> X-Virus-Scanned: clamav-milter 0.96.1 at relay002.lsu.edu X-Virus-Status: Clean Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 18:23:30 -0000 On Wed, Aug 18, 2010 at 02:06:28PM -0400, Andrew Sullivan wrote: > On Wed, Aug 18, 2010 at 10:34:08AM -0700, Nicholas Weaver wrote: [...] > The trouble in the case of the AD bit is that it's too little > information. But we don't get to dismiss that use case just because > we're currently not sure how to answer the query. And we might have > an opportunity here to address such issues (I kinda doubt it, but > maybe). > > > to do the validating: the application NEEDS to tell the host to > > validate and how to treat validation failures (because the default > > will be wrong, no matter what the default is, unless the default is > > I think this is right. It sounds to me like an API issue. The > present one is likely the wrong list for that, though. I wish I knew > what to suggest apart from dnssec-deployment. What ever happened to draft-hayatnagarkar-dnsext-validator-api btw ? Perhaps this is now relevant enough to resurrect ? Regards, Anthony Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F95A3A699C for ; Wed, 18 Aug 2010 11:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.673 X-Spam-Level: X-Spam-Status: No, score=-101.673 tagged_above=-999 required=5 tests=[AWL=0.926, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1FTBNqLGfqN for ; Wed, 18 Aug 2010 11:05:57 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id E23103A6782 for ; Wed, 18 Aug 2010 11:05:55 -0700 (PDT) Received: from crankycanuck.ca (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 2E5581ECB408 for ; Wed, 18 Aug 2010 18:06:30 +0000 (UTC) Date: Wed, 18 Aug 2010 14:06:28 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20100818180628.GK92904@shinkuro.com> Mail-Followup-To: keyassure@ietf.org References: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> <20100818171331.GI92904@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 18:05:59 -0000 On Wed, Aug 18, 2010 at 10:34:08AM -0700, Nicholas Weaver wrote: > NOTHING I said implied that the application does the validating, Well, there were two ways I found to interpret your argument, and the other one seemed to me to be the well-worn arguments about why offloading to an upstream validator was a Bad Idea. I didn't figure you'd be hauling that argument to this list from another one, but I guess I was wrong. In the enterprise situation, we _have_ an implementer who is using the AD bit and IPSEC for the last hop. You keep insisting that's a dangerous model, but in the enterprise environment it isn't necessarily (and arguing from home-user-to-ISP analogies is simply irrelevant). The trouble in the case of the AD bit is that it's too little information. But we don't get to dismiss that use case just because we're currently not sure how to answer the query. And we might have an opportunity here to address such issues (I kinda doubt it, but maybe). > to do the validating: the application NEEDS to tell the host to > validate and how to treat validation failures (because the default > will be wrong, no matter what the default is, unless the default is I think this is right. It sounds to me like an API issue. The present one is likely the wrong list for that, though. I wish I knew what to suggest apart from dnssec-deployment. > And that using such an API for validating A records is useless, > since any application thats smart enough to bother asking "is this A > record validated" is smart enough to realize that the A record > validation is meaningless [1]: a corrupted A record is just simply > one of many possible MitM attacks, so focus on blocking MitM > attacks, not A records: from an application viewpoint, there is no > difference between a poisoned DNS entry, a poisoned ARP cache, BGP > games, or a WiFi packet injector: a MitM is a MitM. So your argument is that if the DNSSEC validation comes back correct, we still aren't sure routing hasn't been compromised, so this is all useless? Surely that's wrong. Another way to do this would be to offload the validation to a trusted DNS server and offload similar validation for BGP &c. to something else, no? I don't really want my phone doing hundreds of DNSSEC validation calculations for every cnn.com page view, do I? > And, frankly speaking, the "benefits" from DNSSEC only come when the > application is aware of DNSSEC I happen to think it is an advantage if I push validation to some layer (or system) I don't have to worry too much about, and then simply get a failure when someone is spoofing the DNS answer. I cheerfully concede it's not a complete solution to every possible problem; but if I were interested in solving world peace and hunger, I'd be a diplomat or a missionary rather than a geek. You appear to be arguing that because DNSSEC validation successes do not prevent attacks on the routing infrastructur, therefore DNSSEC validation does no good. That strikes me as a hard position to maintain. -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BDF43A67B2 for ; Wed, 18 Aug 2010 10:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHzHBAjm9JH5 for ; Wed, 18 Aug 2010 10:51:30 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 9C01A3A6801 for ; Wed, 18 Aug 2010 10:51:30 -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 8682EBC07; Wed, 18 Aug 2010 13:52:05 -0400 (EDT) Date: Wed, 18 Aug 2010 13:52:05 -0400 (EDT) From: Paul Wouters To: Nicholas Weaver In-Reply-To: Message-ID: References: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> <20100818171331.GI92904@shinkuro.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:51:31 -0000 On Wed, 18 Aug 2010, Nicholas Weaver wrote: > And that using such an API for validating A records is useless, since any application thats smart enough to bother asking "is this A record validated" is smart enough to realize that the A record validation is meaningless [1]: a corrupted A record is just simply one of many possible MitM attacks, so focus on blocking MitM attacks, not A records: from an application viewpoint, there is no difference between a poisoned DNS entry, a poisoned ARP cache, BGP games, or a WiFi packet injector: a MitM is a MitM. Not all DNS entries are meant for A records. What if I have an OTR fingerprint record, that I use further down whatever IM network I have access to (jabber, MSN, whatever) > And, frankly speaking, the "benefits" from DNSSEC only come when the application is aware of DNSSEC: the benefits actually lie in the domain of this group: developing ways of using DNSSEC to validate key material or other data directly. Yes, I was saying just the AD bit might not be enough, because we don't want applications to need to do a lot of DNS(SEC) work on the error condition. > [1] Assuming that the resolver has suitable protections against out of path adversaries, of course, or that the host contains its own recursive resolver. My assumption is always the end node is running its own resolver. You can't really trust anything else. So local validation+cache using a DHCP supplied forwarder when possible (using something like unbound that has protection against DNSSEC stripping) Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F043A6A0B for ; Wed, 18 Aug 2010 10:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.583 X-Spam-Level: X-Spam-Status: No, score=-1.583 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YUSOqSvtjuO for ; Wed, 18 Aug 2010 10:36:05 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id D1A483A68D8 for ; Wed, 18 Aug 2010 10:34:39 -0700 (PDT) Received: by pvg7 with SMTP id 7so365762pvg.31 for ; Wed, 18 Aug 2010 10:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=WTU4fJkDju6oDVzeEkMUllh+R4lfYVPwrIzOu7a760s=; b=M/8z82eft+6y6KVv0gA11pmi8ONGWM3yEPcZd7X4Xk+5NGF6ZdUuk8vvKeuvj0jcxw iXeXsDatLg4xRlMRTJ/2nddAWu9b/qkNMT1QU8bT4/PcwLKAST57NKvtAfP3e7a+Q9hl V3DaWoEL7sXQhHGCcNB9ZyxvxfzA+yzx/jVso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=NkomoidhKqTJ245YqCF1WfGtoaQm+5iSKlZTEIPB+MP9y/B+3hMcc9vmekrvMf3IRU s6mWC5YK9H3Jw98Wid5RjejTOsrVKjEKWk/13L89KEoaWBRoq5jlrJJm9FHtmxqr3FiZ h6PQvhofn1fmga0H0TNp4FxTVS7sjx5aFJ4+U= Received: by 10.142.229.19 with SMTP id b19mr7317995wfh.183.1282152852822; Wed, 18 Aug 2010 10:34:12 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id v38sm572610wfh.12.2010.08.18.10.34.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 10:34:11 -0700 (PDT) Sender: Nicholas Weaver References: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> <20100818171331.GI92904@shinkuro.com> In-Reply-To: <20100818171331.GI92904@shinkuro.com> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 18 Aug 2010 10:34:08 -0700 To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:36:13 -0000 NOTHING I said implied that the application does the validating, just = that the application uses an API that does/indicates the need to do the = validating: the application NEEDS to tell the host to validate and how = to treat validation failures (because the default will be wrong, no = matter what the default is, unless the default is to say 'sod DNSSEC'), = and the validation does need to be done on the end host (see previous = rants on what should be done with existing APIs and DNSSEC...). =20 And that using such an API for validating A records is useless, since = any application thats smart enough to bother asking "is this A record = validated" is smart enough to realize that the A record validation is = meaningless [1]: a corrupted A record is just simply one of many = possible MitM attacks, so focus on blocking MitM attacks, not A records: = from an application viewpoint, there is no difference between a poisoned = DNS entry, a poisoned ARP cache, BGP games, or a WiFi packet injector: a = MitM is a MitM. And, frankly speaking, the "benefits" from DNSSEC only come when the = application is aware of DNSSEC: the benefits actually lie in the domain = of this group: developing ways of using DNSSEC to validate key material = or other data directly. [1] Assuming that the resolver has suitable protections against out of = path adversaries, of course, or that the host contains its own recursive = resolver. On Aug 18, 2010, at 10:13 AM, Andrew Sullivan wrote: > On Wed, Aug 18, 2010 at 09:58:20AM -0700, Nicholas Weaver wrote: >>> 6) Think about application requests, eg "I only want the A record = when it was >>> DNSSEC validated" >>=20 >> You example of this is worse than useless. Any application smart = enough to ask that question should be smart enough to not need to trust = the answer. >>=20 >=20 > That's insane. What you're suggesting is that every application needs > to have its own full, DNSSEC-aware validator inside it. The answer to > "the whole world has access to ring 0 on this operating system" is not > to write a mini OS inside every application. It's to make the OS > secure enough so that applications running inside it can trust > facilities offered by the OS. >=20 > If we need every application that wants DNSSEC benefits to have to > understand DNS and DNSSEC, we will never get anywhere. The platform > needs to provide simple, easy access to sec_getaddrinfo() or whatever. > Otherwise, application builders simply won't use that facility. They > have enough work to do. Our job down in the DNS layer is not to make > it impossible for higher-layer applications to use our facilities; > it's to make the facilities easy and natural, so that the best things > we can do are automatically available to application developers. >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711DE3A69E4 for ; Wed, 18 Aug 2010 10:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trj6JH-Ij9y0 for ; Wed, 18 Aug 2010 10:35:02 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id E853F3A6801 for ; Wed, 18 Aug 2010 10:33:51 -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 1D5F8BC07; Wed, 18 Aug 2010 13:32:09 -0400 (EDT) Date: Wed, 18 Aug 2010 13:32:08 -0400 (EDT) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org, Phillip Hallam-Baker Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:36:11 -0000 On Wed, 18 Aug 2010, Ben Laurie wrote: > Back when I worked on DNSSEC, I had a proposal to allow bilateral signing of DNSSEC keys. The general idea was that I > would probably trust my own DNSSEC provider, so I could then retrieve the DNSSEC keys they trusted, and so on, > recursively. Obviously I can choose wherever I like in this graph to start. And related to that, you could keep the trust path from root to yourself. Then when doing any kind of device syncing with a new device, you pass along each others trust path, and it should hit a common trust anchor. This way phone.ben.laurie.org. can sync up with phone.paul.xelerance.com without even *having* any kind of internet uplink. This would be good to have in bonjour/avahi/whateveritiscalled today Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39FA3A67FD for ; Wed, 18 Aug 2010 10:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi6v0BVTvs5I for ; Wed, 18 Aug 2010 10:24:32 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 4EEEC3A6844 for ; Wed, 18 Aug 2010 10:24:32 -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 AAE55BC07; Wed, 18 Aug 2010 13:25:06 -0400 (EDT) Date: Wed, 18 Aug 2010 13:25:06 -0400 (EDT) From: Paul Wouters To: Nicholas Weaver In-Reply-To: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> Message-ID: References: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:24:33 -0000 On Wed, 18 Aug 2010, Nicholas Weaver wrote: >> 1) Key packaging (eg using raw keys or using certificates or using usage bits) > > Or hashes of keys. This would be my vote, as a hash allows Yes, hashes is what i meant with "raw key", sorry. >> 2) Try to make a new DNS record that can be used by more then just one >> application (eg not SSHFP) to avoid spamming the apex. >> 3) Try to make the new DNS record specific enough that we can request specific >> ones (eg I need the key for TLS over SMTP, not the ipsec or ssh key) > > Hmm, this would require some sort of subdomain scheme then, eg > KEYMATERIAL ssl.www.mydomain.com -> RR for SSL key > KEYMATERIAL ssh.www.mydomain.com -> RR for ssh key We could have sub typing instead. That would avoid ugly name space collison, eg if I have a server named ssl.mydomain.com. > Does that really make things better vs > KEYMATERIAL www.mydomain.com -> {ssl-fingerprint: X, ssh-fingerprint: Y}?? that could get big with 10 different apps on a server? >> 6) Think about application requests, eg "I only want the A record when it was >> DNSSEC validated" > > You example of this is worse than useless. Any application smart enough to ask that question should be smart enough to not need to trust the answer. The example was bad because it is actually covered by the AD bit, yes. Let's say "I only want the A record when you can get data through an anonymizer" We currently can only ask for "passed validation", which is limiting. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005D13A67FE for ; Wed, 18 Aug 2010 10:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.66 X-Spam-Level: X-Spam-Status: No, score=-101.66 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-Z3DHWCDKl9 for ; Wed, 18 Aug 2010 10:15:21 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id EB7DD3A67FD for ; Wed, 18 Aug 2010 10:15:20 -0700 (PDT) Received: from crankycanuck.ca (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 E80A71ECB408 for ; Wed, 18 Aug 2010 17:15:55 +0000 (UTC) Date: Wed, 18 Aug 2010 13:15:54 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20100818171554.GJ92904@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:15:22 -0000 On Wed, Aug 18, 2010 at 06:06:35PM +0100, Ben Laurie wrote: > The WG carefully defined the problem s.t. this was not a solution :-) Note that some of us who did the review of the proposals, however, thought that the solution was a good idea worth pursuing, but not one that would solve the particular problem as it was defined. I'm still interested in your proposal, because it seemed like a generally good idea to me (especially in the current context, which is the sort of thing I thought it'd be nice for), A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF4D83A67FD for ; Wed, 18 Aug 2010 10:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.646 X-Spam-Level: X-Spam-Status: No, score=-101.646 tagged_above=-999 required=5 tests=[AWL=0.953, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX8xUvC-hsnS for ; Wed, 18 Aug 2010 10:12:58 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id B80EF3A699C for ; Wed, 18 Aug 2010 10:12:58 -0700 (PDT) Received: from crankycanuck.ca (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 775311ECB408 for ; Wed, 18 Aug 2010 17:13:33 +0000 (UTC) Date: Wed, 18 Aug 2010 13:13:31 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20100818171331.GI92904@shinkuro.com> References: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:12:59 -0000 On Wed, Aug 18, 2010 at 09:58:20AM -0700, Nicholas Weaver wrote: > > 6) Think about application requests, eg "I only want the A record when it was > > DNSSEC validated" > > You example of this is worse than useless. Any application smart enough to ask that question should be smart enough to not need to trust the answer. > That's insane. What you're suggesting is that every application needs to have its own full, DNSSEC-aware validator inside it. The answer to "the whole world has access to ring 0 on this operating system" is not to write a mini OS inside every application. It's to make the OS secure enough so that applications running inside it can trust facilities offered by the OS. If we need every application that wants DNSSEC benefits to have to understand DNS and DNSSEC, we will never get anywhere. The platform needs to provide simple, easy access to sec_getaddrinfo() or whatever. Otherwise, application builders simply won't use that facility. They have enough work to do. Our job down in the DNS layer is not to make it impossible for higher-layer applications to use our facilities; it's to make the facilities easy and natural, so that the best things we can do are automatically available to application developers. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2D63A68DE for ; Wed, 18 Aug 2010 10:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.976 X-Spam-Level: X-Spam-Status: No, score=-104.976 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ca3XzqdQitJ for ; Wed, 18 Aug 2010 10:06:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id E8BE23A6782 for ; Wed, 18 Aug 2010 10:06:02 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o7IH6b7Z000441 for ; Wed, 18 Aug 2010 10:06:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282151197; bh=Pke/eOg9CuAEyrgQET9ghlx9D9U=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=JqYHupmA3+xC2KBkZHrAi2zOJFz2h4QAgalremB3yhIaN125l4srV4fGV4pj8qXFC YYRQahd7WYDPfXTcCRz0A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=XsWQ3mjRxXi/IJPEK8lZVyTLUEY8k6jji7Cswhom88bTpbh9X9R5lib9zZ+Pvm0rR QwyJjvGOfqDpdrAyFvQrA== Received: from vws3 (vws3.prod.google.com [10.241.21.131]) by hpaq1.eem.corp.google.com with ESMTP id o7IH6ZJJ007628 for ; Wed, 18 Aug 2010 10:06:36 -0700 Received: by vws3 with SMTP id 3so894731vws.33 for ; Wed, 18 Aug 2010 10:06:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.125.38 with SMTP id w38mr5261710vcr.49.1282151195479; Wed, 18 Aug 2010 10:06:35 -0700 (PDT) Received: by 10.220.58.137 with HTTP; Wed, 18 Aug 2010 10:06:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Aug 2010 18:06:35 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001636b1462e8e0fa4048e1c16a3 X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:06:04 -0000 --001636b1462e8e0fa4048e1c16a3 Content-Type: text/plain; charset=ISO-8859-1 On 18 August 2010 16:17, Phillip Hallam-Baker wrote: > I don't agree with the idea that a single root of trust is desirable > or provides any advantage whatsoever. It is one of the features we > need to fix. The Internet is a network of peers, not serfs. The Icann > scheme has it's uses but it does not have to be the only scheme people > are allowed to use. > > I am my own root of trust. And that is what everyone else should demand. > Back when I worked on DNSSEC, I had a proposal to allow bilateral signing of DNSSEC keys. The general idea was that I would probably trust my own DNSSEC provider, so I could then retrieve the DNSSEC keys they trusted, and so on, recursively. Obviously I can choose wherever I like in this graph to start. The WG carefully defined the problem s.t. this was not a solution :-) --001636b1462e8e0fa4048e1c16a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 18 August 2010 16:17, Phillip Hallam-Baker <hallam@gmail.com> wrote:
I don't agree with the idea that a single root of trust is desirable or provides any advantage whatsoever. It is one of the features we
need to fix. The Internet is a network of peers, not serfs. The Icann
scheme has it's uses but it does not have to be the only scheme people<= br> are allowed to use.

I am my own root of trust. And that is what everyone else should demand.

Back when I worked on DNSSEC, I had a pro= posal to allow bilateral signing of DNSSEC keys. The general idea was that = I would probably trust my own DNSSEC provider, so I could then retrieve the= DNSSEC keys they trusted, and so on, recursively. Obviously I can choose w= herever I like in this graph to start.

The WG carefully defined the problem s.t. this was not = a solution :-)
=A0
--001636b1462e8e0fa4048e1c16a3-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279543A67FD for ; Wed, 18 Aug 2010 09:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=1.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwbi3nwQDwhs for ; Wed, 18 Aug 2010 09:57:52 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DF02D3A698A for ; Wed, 18 Aug 2010 09:57:51 -0700 (PDT) Received: by iwn3 with SMTP id 3so902479iwn.31 for ; Wed, 18 Aug 2010 09:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=wc4zFm3Pe18/+DM+VYOj1HWj0OpAGBuSFxso5DG8qFU=; b=bpDhOlGf/APuXXT4YeKx8nZkxkI1JCvttNe/3CX4LNNQwYxpz4Tqac8QDigH6sNVgu pBhiZAy3Yw03PjxO8EvhMt4dMhlx5oASngjqNoCZuwlbx9DKVraTc5fTOKvGfhysajRe qtPuRzSMfb6cBmKfukAplqaHYQ+Eg4mDIU4E4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=RPaInooUxKmm9CLJJL0qHLb8Y3jpy1PoMXX9nRY6b8ywtPZHotPpI428iI11ravtxW pH4M5QGBgrPvJnxN/P/5LporPElN7VfWwMJEYToPEBQzXX0A4oOf5CJXaLvKhrpNFSbC PRMnu2wNQaW1CQzXCd4IHtWHzDqyaDb2gghTU= Received: by 10.231.15.70 with SMTP id j6mr9045420iba.141.1282150707001; Wed, 18 Aug 2010 09:58:27 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id r3sm394620ibk.19.2010.08.18.09.58.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 09:58:23 -0700 (PDT) Sender: Nicholas Weaver References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <137B47C5-CCD5-4D5F-9DD2-27EE55C8CF32@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 18 Aug 2010 09:58:20 -0700 To: Paul Wouters X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:57:53 -0000 On Aug 18, 2010, at 9:30 AM, Paul Wouters wrote: >=20 > Hi, >=20 > First of all, thanks for starting this list. I have been talking to = various people to do precisely this.... >=20 > As I see it, we have a few problems to resolve. >=20 > 1) Key packaging (eg using raw keys or using certificates or using = usage bits) Or hashes of keys. This would be my vote, as a hash allows a) Efficient recording of data b) Sufficient information to validate the actual received data is legit = in the existing protocol key exchange. > 2) Try to make a new DNS record that can be used by more then just one > application (eg not SSHFP) to avoid spamming the apex. > 3) Try to make the new DNS record specific enough that we can request = specific > ones (eg I need the key for TLS over SMTP, not the ipsec or ssh key) Hmm, this would require some sort of subdomain scheme then, eg KEYMATERIAL ssl.www.mydomain.com -> RR for SSL key KEYMATERIAL ssh.www.mydomain.com -> RR for ssh key Does that really make things better vs KEYMATERIAL www.mydomain.com -> {ssl-fingerprint: X, ssh-fingerprint: = Y}?? Especially since if its hashes/fingerprints, the data is small = (~256b/entry) > 6) Think about application requests, eg "I only want the A record when = it was > DNSSEC validated" You example of this is worse than useless. Any application smart enough = to ask that question should be smart enough to not need to trust the = answer. Application requests for validation are essential, but the records being = validated are key fingerprints or other material where it is the = material itself that needs to be authentic, thus keystore records, TXT = records, etc will be the ones validated. This is also why I believe this group is essential if DNSSEC is to do = ANY good what-so-ever. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A143A65A6 for ; Wed, 18 Aug 2010 09:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.631 X-Spam-Level: X-Spam-Status: No, score=-101.631 tagged_above=-999 required=5 tests=[AWL=0.968, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56XIVEwP24lb for ; Wed, 18 Aug 2010 09:38:49 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 81F9D3A67F1 for ; Wed, 18 Aug 2010 09:38:49 -0700 (PDT) Received: from crankycanuck.ca (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 EC1731ECB408 for ; Wed, 18 Aug 2010 16:39:23 +0000 (UTC) Date: Wed, 18 Aug 2010 12:39:22 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20100818163921.GG92904@shinkuro.com> References: <201008181611.o7IGBeQQ009528@fionn.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008181611.o7IGBeQQ009528@fionn.es.net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:38:51 -0000 > > 1 - DNSSEC can tell me who owns some DNS data, like an assertion about > a hostname. I don't think I know any more than that. That's pretty > important, but > > 2 - X.509 certificates could tell me a lot more about what I can expect > from the transaction I am starting. It can deliver a level of assurance > attribute, a policy pointer of some kind that can lead to a complete > disclosure of what this certificate means, and other attributes that > describe what this certificate is supposed to permit or deny. I don't > think this is available in DNSSEC. We can argue about the utility of > some of this but that's not the issue. > > Another way of looking at it - this should be up the stack & closer to > the application's viewpoint than DNS is (should be). So perhaps It seems to me that this distinction is one on which we foundered during the BOF, too. There are two completely different use cases for TLS, and we will get nowhere if we assert that solutions for one are inadequate solutions for the other. The goal in the current keys-linkage draft, as I read it, is simply to gain some assurance that the PKIX cert in question is actually associated with the domain it claims to be. That is by no means any kind of assurance that (say) the domain is actually operated by the organization one thinks it is (i.e. it doesn't prove that www.mybank.com is actually operated by My Bank, member FDIC). The first of those is not too far from your (1) (but I think your description doesn't quite capture the power of being able to guarantee you got the right result from the DNS). The second of these is plainly related to your (2). The fact is that many people think (2) is a waste of time for many purposes: many of the actual CAs simply don't do anything like the job necessary to believe their assertions about identity and so on embodied in the cert. Therefore, the "utility of some of this" is not the issue directly, but it certainly is a motivating factor in the discussion. I don't think we can dismiss it. If the facilities that are supposed to be offered by a technology don't work in practice, then the lack of utility is relevant to rhe duscussion. (This is not to say the facilities are never useful. But as general infrastructure, they haven't worked out so well in terms of actually identifying complete strangers to one anhother.) > There is also going to be a place for self-signed certificates > whose integrity (not necessarily trust) is guaranteed by a relationship > with DNSSEC-secured data. Right. My impression is that such is the thing this proposed WG would aim at. That's congruent with my reading of the Problem Statement recently circulated. Complete replacement of the entire X.509 functionality is obviously not needed. Perhaps, however, a supplementary way of anchoring CAs (better than "update your browser, please"!) would be another nice thing for any WG to develop. I regard that as a sideshow, however. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7323A697F for ; Wed, 18 Aug 2010 09:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGMiYT84XFyl for ; Wed, 18 Aug 2010 09:29:25 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 99CFF3A6942 for ; Wed, 18 Aug 2010 09:29:25 -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 8F2A0C17D for ; Wed, 18 Aug 2010 12:30:00 -0400 (EDT) Date: Wed, 18 Aug 2010 12:30:00 -0400 (EDT) From: Paul Wouters To: keyassure@ietf.org Message-ID: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [keyassure] Thanks for starting this - my wishlist :) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:29:27 -0000 Hi, First of all, thanks for starting this list. I have been talking to various people to do precisely this.... As I see it, we have a few problems to resolve. 1) Key packaging (eg using raw keys or using certificates or using usage bits) 2) Try to make a new DNS record that can be used by more then just one application (eg not SSHFP) to avoid spamming the apex. 3) Try to make the new DNS record specific enough that we can request specific ones (eg I need the key for TLS over SMTP, not the ipsec or ssh key) 4) Think about EDNS (secure?) signaling to reduce latency when asking for something that will contain an additional trust type record 5) Think about EDNS signaling to request "anonymity". This could be used by a browser to request a a local DNS server to not resolve itself, but to use a proxy/SOCKS/forwarding servce (eg tor) to aggregate or disguse DNS requests. 6) Think about application requests, eg "I only want the A record when it was DNSSEC validated" 7?) think about reducing the size of any new record as much as possible One link that was missing from the summary send to the list before was the original KEY record. It did try to distinguish between applications/protocols (just only DNSSEC was assigned) ftp://ftp.rfc-editor.org/in-notes/rfc2535.txt For instance, see section 3.1.3 The Protocol Octet that talks about application usage. The RFC that then obsoleted application use is: ftp://ftp.rfc-editor.org/in-notes/rfc3445.txt I personally think that if we use the trust model of DNSSEC, we should not have any CA's. However, we probably do need to have "usage bits", which also exist within the X.509/ASN.1 space, so perhaps it is prudent to re-use some of that? I think the biggest immediate win, will be to get HTTPS raw keys in DNSSEC, supported in a browser like firefox, reducing the 80% of warnings from self-signed SSL certs that are out there right now. A next logical step might be to see if we could use the DNS to see if we should start out with HTTPS (and not HTTP) when connecting to site. Eg the pressense of a bit or a flag that gives a preference on how to be contacted. (eg HTTPS preferred pver HTTP, or HTTPS only) Last, there *might* be a need to say "return even mangled stuff", which could potentially be used when you're trying to get through a hotspot/payportal location, where you send a DNS probe for the sole reason of getting it mangled for portal access. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6733A698B for ; Wed, 18 Aug 2010 09:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLQC4xqU2Amj for ; Wed, 18 Aug 2010 09:25:54 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2AF5F3A697F for ; Wed, 18 Aug 2010 09:25:54 -0700 (PDT) Received: by iwn3 with SMTP id 3so880013iwn.31 for ; Wed, 18 Aug 2010 09:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=cSvZU7JQMhlWuS1SZXWSszirQvOfw0USZXXepCFZv4o=; b=AJyJwDSzCtrrcBDXPbPLqsonzZNbjDVIv7/mqM7rdI/4uX4UxtviyeBsEkPQN84MWI IPlGlUjl41PdnNmdg7gJrZrhTSrBq3bbzN8USFoi/yM96vOkCzYPfCXm59qsYV10VCkX x6whA8D0A1CZ7VEGfrppnHUk+okeRkV34lmNw= 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=uIamyBqLqG/2Xo1MPBNR4XrdDIroBwxwu48Gs5ZgR+Hep1rjQ2DmxK6Wx61Z68Vbjw 3gtFD36iCA3n7pxb40Ax8tJFbbaGhThSgt15RIyktqaE6RUH1PPLW9Ss/+OONvZbPiTS nmulo/DTKaIoxIKEfIe+UQYLVRgk6lTpVJMsU= MIME-Version: 1.0 Received: by 10.231.167.130 with SMTP id q2mr9408386iby.163.1282148788489; Wed, 18 Aug 2010 09:26:28 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Wed, 18 Aug 2010 09:26:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Aug 2010 12:26:28 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org, Carl Wallace Subject: Re: [keyassure] to validate or not to validate? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:25:55 -0000 I have been working on this problem for some time. The scheme I came up with was: 1) Create a new RR for end entity cert disclosure with the following attributes: * Digest algorithm + Digest value * URL for retrieval of cert chain (optional) * DNS record prefix for use in disambiguating multiple certs associated with the same domain (optional). 2) Create an X.509v3 certificate extension for DNS path chain validation. This takes as an attribute a prefix value. If we are going to modify an application's use of DNS then lets not do half measures. Lets do the job right and make the best use of DNS features that we can. If a Web browser is going to be looking at the DNS for keys, then lets take the time to take advantage of SRV as well. So lets imagine that we have a HTTP/SSL service that is served using 4 different servers. Each of which has its own certificate. This is highly desirable regardless of the type of certificate. The certificate can be self signed, it can be issued under a local CA with a local trust root, it can be issued as Domain Validated or it can even be an EV certificate. Different relying parties may validate the same certificate along different trust paths for different purposes. So it may be that in some cases you would want to validate the cert along the X.509v3 path alone, in others you would want to have the additional verification of a DNSSEC validated path. For example, X.509v3 wildcard certificates currently only support *.example.com. It would be nice for the subject to be able to lock them down to specific domains. Each server has their own key and thus their own cert. Each has a DNSHASH extension as follows: www1.example.com ->> DNSHASH (c1) www2.example.com ->> DNSHASH (c2) www3.example.com ->> DNSHASH (c3) www4.example.com ->> DNSHASH (c4) On the DNS side there is a round robin A record for backwards compatibility and a series of SRV records.: www.example.com A [10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4 _http._srv.example.com SRV 1 1 80 www1.example.com _https._srv.example.com SRV 1 1 443 www1.example.com _http._srv.example.com SRV 1 1 80 www2.example.com _https._srv.example.com SRV 1 1 443 www2.example.com _http._srv.example.com SRV 1 1 80 www3.example.com _https._srv.example.com SRV 1 1 443 www3.example.com _http._srv.example.com SRV 1 1 80 www4.example.com _https._srv.example.com SRV 1 1 443 www4.example.com www1.example.com A 10.0.0.1 www2.example.com A 10.0.0.1 www3.example.com A 10.0.0.1 www4.example.com A 10.0.0.1 _c1.example.com CERTH "h=SHA1:bd0e87ecc53c4d961ef55f3b4bb47dd06ff8c825" _c2.example.com CERTH "h=SHA1:f55ad283945cdc4903bf8c22b04074ada5d20104" _c3.example.com CERTH "h=SHA1:0f3ba85b555d74cfd653dabb74046220ccdc5ba1" _c4.example.com CERTH "h=SHA1:160c9cd8877025be44c790653815b949986ebd54" >From the relying party point of view: 1) Resolve www.example.com to obtain an A record for use with HTTP/TCP 2) Decide to use SSL [Will explain this in more detail in a later post] 3) Connect to the IP address with SSL [Require use of the domain extension] 4) Server pushes out its certificate - Certificate specifies DNSHASH c3 5) Pull _c3.www.example.com CERTH * Verify that CERTH specifies acceptably secure algorithm * Verify digest value for acceptable algorithm matches cert. * Verify the trust path on the CERTH RR. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60CDB3A6953 for ; Wed, 18 Aug 2010 09:22:07 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYrKbmYOXsSq for ; Wed, 18 Aug 2010 09:22:06 -0700 (PDT) Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id 070F43A6855 for ; Wed, 18 Aug 2010 09:22:05 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o7IGMe70020503 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 18 Aug 2010 12:22:40 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o7IGMdpF024210 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 Aug 2010 12:22:40 -0400 (EDT) Message-Id: <173650CE-54EC-4290-9772-3D15441D2223@princeton.edu> From: Stephen Schultze To: keyassure@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Aug 2010 12:22:39 -0400 References: X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6077 signatures=637960 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008180106 Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:22:07 -0000 On Aug 18, 2010, at 11:40 AM, Nicholas Weaver wrote: > On Aug 18, 2010, at 8:17 AM, Phillip Hallam-Baker wrote: >> I don't agree with the idea that a single root of trust is desirable >> or provides any advantage whatsoever. It is one of the features we >> need to fix. The Internet is a network of peers, not serfs. The Icann >> scheme has it's uses but it does not have to be the only scheme >> people >> are allowed to use. > > Yet at the same time you argue that the CA vendors provide > something? This seems strange. You MUST HAVE either a set of trust > roots (any PKI) or a notion of consensus (PGP) or a leap-of-faith > (ssh). > > DNSSEC and CA's are "trust root" models. Face it, because its a > trust root model, you must have, well, a trust root. You might be > able to hack a consensus model onto DNSSEC, but that would be > difficult, especially since normal DNS already has a trust root > model in operation. > > But if you are going to have a trust-root, you really only want a > single point or single possible path of trust, because of attacks on > the CA infrastructure itself. With a gazillion roots of trust, and > roots of trust willing to delegate completely given enough money > (eg, the Verizon provided Etisalat * cert [1]), the system is weak. > > And thus the big advantage of DNSSEC over other PKIs, other than > cost (EG, CA vendors charge $150+ for *.mydomain wildcards, which is > just highway robbery) is that the trust path is limited: the trust > path for things in mydomain.com ONLY depend on mydomain.com, .com, > and .: there's no longer the case that MY ssl infrastructure is > trivially vulnerable because Verizon's division decided to sign a * > cert for the UAE. It seems that you both can be right. I certainly agree with PHB's statement that each system has its benefits and weaknesses, and the goal of keys-in-DNS is not to completely supplant the CA model. The benefit of a DNSSEC-based model is that it provides trust in authenticating the controller of a domain name, at which point you can bootstrap to additional trust provided by CAs or others ad needed. One key advantage, as Nicholas observes, is excludability in the first step of trust. PHB would like to also give flexibility to end-users to specify additional or alternative TAs within DNS. Perhaps this will be useful for some entities that maintain large public zones, or their own internal zones, or for other purposes. If users choose to add other TAs, it seems that should be permitted as a matter of technology and policy (we saw this with the DLV). They do so with the conscious understanding that they are trusting an additional/different authority (either at the root or an intermediate node), which is far better than the current system in which arbitrary unknown SubCAs exist in the wild. I personally think it most likely that the vast majority of users will have just the one signed root TA for DNSSEC trust, but I don't see how it's productive to argue over whether this will be the case in general. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E56A3A67F9 for ; Wed, 18 Aug 2010 09:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vISnVn-6PYqx for ; Wed, 18 Aug 2010 09:12:19 -0700 (PDT) Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by core3.amsl.com (Postfix) with ESMTP id 39E1D3A69F2 for ; Wed, 18 Aug 2010 09:11:29 -0700 (PDT) Received: from fionn.es.net (localhost [127.0.0.1]) by fionn.es.net (8.13.7+Sun/8.13.7) with ESMTP id o7IGBeQQ009528 for ; Wed, 18 Aug 2010 09:11:40 -0700 (PDT) Message-Id: <201008181611.o7IGBeQQ009528@fionn.es.net> To: keyassure@ietf.org In-reply-to: Your message of "Wed, 18 Aug 2010 08:40:07 PDT." Date: Wed, 18 Aug 2010 09:11:39 -0700 From: Mike Helm Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: helm@fionn.es.net List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:12:25 -0000 Nicholas Weaver writes: > On Aug 18, 2010, at 8:17 AM, Phillip Hallam-Baker wrote: > > I don't agree with the idea that a single root of trust is desirable > > or provides any advantage whatsoever. It is one of the features we > > need to fix. The Internet is a network of peers, not serfs. The Icann > > Yet at the same time you argue that the CA vendors provide something? This seems strange. You MUST HAVE either a set of trust roots (any PKI) or a notion of consensus (PGP) or a leap-of-faith (ssh). I see 2 (or maybe 3) problems, which themselves are probably anchored in the interpretation of trust. From the relying party point of view, 1 - DNSSEC can tell me who owns some DNS data, like an assertion about a hostname. I don't think I know any more than that. That's pretty important, but 2 - X.509 certificates could tell me a lot more about what I can expect from the transaction I am starting. It can deliver a level of assurance attribute, a policy pointer of some kind that can lead to a complete disclosure of what this certificate means, and other attributes that describe what this certificate is supposed to permit or deny. I don't think this is available in DNSSEC. We can argue about the utility of some of this but that's not the issue. Another way of looking at it - this should be up the stack & closer to the application's viewpoint than DNS is (should be). So perhaps 3 - SSL/TLS is bit trapped. Current best (or typical) practices for hosts seem to be to focus on the domain owner to give permission for certificates to be issued. Sometimes this is very counterproductive - the domain owner might be a network engineer largely univolved with the application that needs TLS. Skipping a long argument, we can liberate SSL/TLS from trying to take the place of DNSSEC - DNSSEC can manage the host name accountability, & TLS / SSL certs can focus on managing the application accountability. This is not going to be a perfect separation but it looks useful. There is going to be a place for 3rd party certificate signers. There is also going to be a place for self-signed certificates whose integrity (not necessarily trust) is guaranteed by a relationship with DNSSEC-secured data. My perspective comes from the grid - academic research distributed computing world where we need more of this flexibility. (Say what you may about that.) Thanks, ==mwh Michael Helm ESnet/LBNL Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8618B3A6848 for ; Wed, 18 Aug 2010 08:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=2.292, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QdDonV7ElQ0 for ; Wed, 18 Aug 2010 08:39:39 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 3D1643A6891 for ; Wed, 18 Aug 2010 08:39:39 -0700 (PDT) Received: by pzk6 with SMTP id 6so327131pzk.31 for ; Wed, 18 Aug 2010 08:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=x26i/pYuXBqiDBfvcG6De+GcRFinNEXZt/Wxy+M3kGc=; b=aKPrPzuNOBTm4C9GCuFTiKCuFtIALx3utnLR1xFA2n96RI+r5nHSIqJ2cQTxyi447U Fl0TzR7R1c5fg8++w81CtYX5y8NCSitOtntmIbzGFpcIt6v3ly809VUfIAC/QZXslQ3w jo2K1tJ//E7O6sBiVF8bSFE+AxHZqat9agFBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=ET091X3XLKS4ceIj0grZ7jdJKq3kFdSb93KXT0p6gQaVvfYAjEuTMJvVGvkpugJODi B2NPXkwB4m2yvw5Wn4MFcVyqXmIjB7nuuV0OJnDovxsQ1BrKk/+hvHvzuGTRsZqgt7+r b8Rp+LK5rTwim7DViiXpr8+QHkTJz3icuER2Y= Received: by 10.115.90.18 with SMTP id s18mr2637055wal.7.1282146011671; Wed, 18 Aug 2010 08:40:11 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id q6sm712247waj.10.2010.08.18.08.40.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 08:40:09 -0700 (PDT) Sender: Nicholas Weaver References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 18 Aug 2010 08:40:07 -0700 To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:39:40 -0000 On Aug 18, 2010, at 8:17 AM, Phillip Hallam-Baker wrote: > I don't agree with the idea that a single root of trust is desirable > or provides any advantage whatsoever. It is one of the features we > need to fix. The Internet is a network of peers, not serfs. The Icann > scheme has it's uses but it does not have to be the only scheme people > are allowed to use. Yet at the same time you argue that the CA vendors provide something? = This seems strange. You MUST HAVE either a set of trust roots (any PKI) = or a notion of consensus (PGP) or a leap-of-faith (ssh). =20 DNSSEC and CA's are "trust root" models. Face it, because its a trust = root model, you must have, well, a trust root. You might be able to = hack a consensus model onto DNSSEC, but that would be difficult, = especially since normal DNS already has a trust root model in operation. But if you are going to have a trust-root, you really only want a single = point or single possible path of trust, because of attacks on the CA = infrastructure itself. With a gazillion roots of trust, and roots of = trust willing to delegate completely given enough money (eg, the Verizon = provided Etisalat * cert [1]), the system is weak. And thus the big advantage of DNSSEC over other PKIs, other than cost = (EG, CA vendors charge $150+ for *.mydomain wildcards, which is just = highway robbery) is that the trust path is limited: the trust path for = things in mydomain.com ONLY depend on mydomain.com, .com, and .: there's = no longer the case that MY ssl infrastructure is trivially vulnerable = because Verizon's division decided to sign a * cert for the UAE. [1] (https://www.eff.org/deeplinks/2010/08/open-letter-verizon) Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C894D3A6947 for ; Wed, 18 Aug 2010 08:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.482 X-Spam-Level: X-Spam-Status: No, score=-5.482 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28PAee3xunAJ for ; Wed, 18 Aug 2010 08:37:20 -0700 (PDT) Received: from mail166.messagelabs.com (mail166.messagelabs.com [216.82.253.163]) by core3.amsl.com (Postfix) with SMTP id 9A0853A697A for ; Wed, 18 Aug 2010 08:37:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-7.tower-166.messagelabs.com!1282145696!36547297!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.25] Received: (qmail 31759 invoked from network); 18 Aug 2010 15:34:57 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.25) by server-7.tower-166.messagelabs.com with SMTP; 18 Aug 2010 15:34:57 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 18 Aug 2010 11:34:55 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [keyassure] to validate or not to validate? Thread-Index: Acs+5lw6QQAIMVDhRyuxrRjWXh4D5wAALeHg References: From: "Carl Wallace" To: "Paul Hoffman" , Subject: Re: [keyassure] to validate or not to validate? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:37:41 -0000 X-List-Received-Date: Wed, 18 Aug 2010 15:37:41 -0000 > >This may be cleaner if the key association comparison was performed > first then PKIX validation checks enforced if required by the client. > A client could then require the extra checks in some cases but not all. >=20 > The current intent, which might not be reflected well in the processing > is: > - If there is no DNS key association, do normal PKIX validation > - If there is one or more key associations, make sure that one of them > matches the key in the server certificate > - If the server certificate looks like it is supposed to chain to a > trust anchor, do the PKIX validation check and fail if it fails > - If the server certificate does not look like it is supposed to chain > to a trust anchor (generally: it is self-signed or signed by a CA that > is not a trust anchor), don't bother doing the PKIX validation and > accept it as-is >=20 > Expressing the fourth part is where we might have tripped up. A > simplification could be to only check if it is self-signed, but I think > there is a real use-case for "I have a cert signed by my organization's > local authority that people in my organization use as a trust anchor > but probably no one else does". It's going to be tricky to define the condition that drives selection of one of the last two bullets. Simply checking for self-signed is probably the safest option. There are lots of sites with certificates issued by a CA that is not a trust anchor, so including a check to see if a certificate is signed by a TA is not a good option. =20 More generally, it does not seem like a good idea to allow the key association check to circumvent the client's trust anchor store. I may want to operate my browser with a very limited set of (ideally constrained) TAs in some scenarios and a broader set in other scenarios. Having the key association check as an additional check is good. Having the key association check serve as the only check is also good in some cases, but not all, hence my suggestion that PKIX enforcement be at the client's discretion. =20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A53E3A6986 for ; Wed, 18 Aug 2010 08:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODZtHPZ8EUg4 for ; Wed, 18 Aug 2010 08:16:57 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 0BE893A696F for ; Wed, 18 Aug 2010 08:16:56 -0700 (PDT) Received: by gxk20 with SMTP id 20so283424gxk.31 for ; Wed, 18 Aug 2010 08:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=FZ78JktLrETkcPEJRnSTy2zuFF2LD9Z1YZkEVT5eO6c=; b=fDnZdgWYqjlocj37GxKCAK6bkcmhbFz0/1jB98qfpyWth5KzQvgx5l4nCzpvABN9V2 2d3GcZdqBKPucsVdgDFynOpx2kRN/+xTtmY0rRaYUlhcNekeYvlHMorK2MSwxaU2dH3b JiFk1gFKEizKBnfdKm5q3T+HeN61h4GR9ucVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=GpdVIZ4O9Q8nXvDn5lLXjUjoEUvH3XNyItDbYZ415WrnuCl0//UqzVetjxNIiZVzO0 FKOZqTy3ropQqqb24UuTgsgHDDe0iuaupp6aHzjxNdg4XOB8JJRoIKtFhthnK0yZDIN+ /q+HwHRbEIBHyJtyLvi5MHVc14UV7EKccWnCU= MIME-Version: 1.0 Received: by 10.151.102.17 with SMTP id e17mr566734ybm.64.1282144650226; Wed, 18 Aug 2010 08:17:30 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Wed, 18 Aug 2010 08:17:30 -0700 (PDT) Date: Wed, 18 Aug 2010 11:17:30 -0400 Message-ID: From: Phillip Hallam-Baker To: keyassure@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [keyassure] Charter discussion - Use of DNSSEC in applications X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:16:58 -0000 I disagree with the statement in the proposed charter We have a pki infrastructure that has certain capabilities and certain limitations. We have the expectation of a dnssec infrastructure with other capabilities and limitations I am not too interested in just re-doing the features already supported in existing pki at lower out of pocket expense What we should do here is to work out how we can use dnssec plus pki to move beyond current capabilities. In particular. * ubiquitous encryption * downgrade attack prevention * best possible security Of course getting rid of the out of pocket expense is a necessary condition for ubiquitous crypto. But you are only going to get a limited amount of security for free. I want to make EV certs work well with Dnssec as an option. If 100% of Internet traffic is encrypted, people may start to see the value of the service that CAs really provide. I don't agree with the idea that a single root of trust is desirable or provides any advantage whatsoever. It is one of the features we need to fix. The Internet is a network of peers, not serfs. The Icann scheme has it's uses but it does not have to be the only scheme people are allowed to use. I am my own root of trust. And that is what everyone else should demand. As a practical matter we can't escape from x.509 entirely. Ssl is set up to use certs. We will do much better to put certs or cert hashes in the dns than raw keys. If we use raw keys we then have to do much More drastic revision to ssl libraries. We have to recode both the client and the server rather than just the client. I hate asn1 as much as anyone, but it's no real pain to wrap a key as a self signed cert. We should look to make the best system we can, not simply replicate what already exists for cheap. -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52CDE3A6891 for ; Wed, 18 Aug 2010 08:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.78 X-Spam-Level: X-Spam-Status: No, score=-99.78 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdWSghq+sptH for ; Wed, 18 Aug 2010 08:01:44 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 7BCA03A6840 for ; Wed, 18 Aug 2010 08:01:44 -0700 (PDT) Received: from [10.20.30.158] (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 o7IF2FUI093423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Aug 2010 08:02:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 18 Aug 2010 08:02:14 -0700 To: "Carl Wallace" , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [keyassure] to validate or not to validate? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:01:45 -0000 At 9:10 AM -0400 8/18/10, Carl Wallace wrote: >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01CB3ED6.B0FD9F6D" >Content-class: urn:content-classes:message > >In section 3, it is difficult to ascertain the relationship between the two bullets. The first clause of the each bullet requires the client to determine if the TLS server's certificate is signed by a CA trusted by the client. This is typically done by applying "PKIX validation checks", which are only applied in the first bullet after making this determination. It's not clear to me if a failed PKIX validation check coupled with a key association match is a success case or a failure case. Is the intent to do full path processing with the issuer's certificate as the end entity before deciding which option to invoke? > >This may be cleaner if the key association comparison was performed first then PKIX validation checks enforced if required by the client. A client could then require the extra checks in some cases but not all. The current intent, which might not be reflected well in the processing is: - If there is no DNS key association, do normal PKIX validation - If there is one or more key associations, make sure that one of them matches the key in the server certificate - If the server certificate looks like it is supposed to chain to a trust anchor, do the PKIX validation check and fail if it fails - If the server certificate does not look like it is supposed to chain to a trust anchor (generally: it is self-signed or signed by a CA that is not a trust anchor), don't bother doing the PKIX validation and accept it as-is Expressing the fourth part is where we might have tripped up. A simplification could be to only check if it is self-signed, but I think there is a real use-case for "I have a cert signed by my organization's local authority that people in my organization use as a trust anchor but probably no one else does". --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8513A6987 for ; Wed, 18 Aug 2010 07:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.784 X-Spam-Level: X-Spam-Status: No, score=-99.784 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQ0jYG+xru7Q for ; Wed, 18 Aug 2010 07:46:08 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9CC253A695B for ; Wed, 18 Aug 2010 07:46:05 -0700 (PDT) Received: from [10.20.30.158] (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 o7IEkdol092581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Aug 2010 07:46:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C6B90C5.8080503@nic.cz> References: <4C6B90C5.8080503@nic.cz> Date: Wed, 18 Aug 2010 07:45:46 -0700 To: keyassure@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [keyassure] Key linkage draft, -00 edition X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 14:46:09 -0000 Greetings again. A gang of us created a draft that pulls together some of the many ideas that have been floating around. There are multiple options for some features, so we chose one option in each category and started an appendix to document the choices. Discussion is welcome. Please don't assume that any of the options are set in stone, although note that changing some options might also require changing other options at the same time. In particular, I think my idea of listing ports is going to go away, given that few sites run services on different ports but keep the same domain name. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90DA73A6950 for ; Wed, 18 Aug 2010 06:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SqNjzEWTzg7 for ; Wed, 18 Aug 2010 06:09:41 -0700 (PDT) Received: from mail152.messagelabs.com (mail152.messagelabs.com [216.82.253.19]) by core3.amsl.com (Postfix) with SMTP id 7F8333A68A0 for ; Wed, 18 Aug 2010 06:09:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-12.tower-152.messagelabs.com!1282137013!40909346!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.25] Received: (qmail 10231 invoked from network); 18 Aug 2010 13:10:13 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.25) by server-12.tower-152.messagelabs.com with SMTP; 18 Aug 2010 13:10:13 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3ED6.B0FD9F6D" X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {8689E3FE-10AD-4B9D-82D8-F35DC145EA85} x-cr-hashedpuzzle: BPsw BVJB BbYn Cxn7 C7/T EUKr F+UY Gues GvXL HD0V H0ig Ifxo Irn5 JPiG JlDK JyDh; 1; awBlAHkAYQBzAHMAdQByAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {8689E3FE-10AD-4B9D-82D8-F35DC145EA85}; YwB3AGEAbABsAGEAYwBlAEAAYwB5AGcAbgBhAGMAbwBtAC4AYwBvAG0A; Wed, 18 Aug 2010 13:10:10 GMT; dABvACAAdgBhAGwAaQBkAGEAdABlACAAbwByACAAbgBvAHQAIAB0AG8AIAB2AGEAbABpAGQAYQB0AGUAPwA= Content-class: urn:content-classes:message Date: Wed, 18 Aug 2010 09:10:10 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: to validate or not to validate? Thread-Index: Acs+1q/0OErLyOKpSYSaVoML4oefoA== From: "Carl Wallace" To: Subject: [keyassure] to validate or not to validate? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 13:09:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3ED6.B0FD9F6D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In section 3, it is difficult to ascertain the relationship between the two bullets. The first clause of the each bullet requires the client to determine if the TLS server's certificate is signed by a CA trusted by the client. This is typically done by applying "PKIX validation checks", which are only applied in the first bullet after making this determination. It's not clear to me if a failed PKIX validation check coupled with a key association match is a success case or a failure case. Is the intent to do full path processing with the issuer's certificate as the end entity before deciding which option to invoke? =20 This may be cleaner if the key association comparison was performed first then PKIX validation checks enforced if required by the client. A client could then require the extra checks in some cases but not all. ------_=_NextPart_001_01CB3ED6.B0FD9F6D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In section 3, it is difficult to ascertain the = relationship between the two bullets.  The first clause of the each bullet = requires the client to determine if the TLS server’s certificate is signed by a = CA trusted by the client.  This is typically done by applying “PKIX = validation checks”, which are only applied in the first bullet after making = this determination.  It’s not clear to me if a failed PKIX = validation check coupled with a key association match is a success case or a = failure case.  Is the intent to do full path processing with the issuer’s = certificate as the end entity before deciding which option to invoke?

 

This may be cleaner if the key association = comparison was performed first then PKIX validation checks enforced if required by the = client.  A client could then require the extra checks in some cases but not = all.

------_=_NextPart_001_01CB3ED6.B0FD9F6D-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96E123A6849 for ; Wed, 18 Aug 2010 00:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPafMh2vgQEH for ; Wed, 18 Aug 2010 00:49:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 380AB3A6A28 for ; Wed, 18 Aug 2010 00:49:55 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id EA724734384 for ; Wed, 18 Aug 2010 09:50:29 +0200 (CEST) Message-ID: <4C6B90C5.8080503@nic.cz> Date: Wed, 18 Aug 2010 09:50:29 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [keyassure] You want to read this :) (Was: Welcome to the mailing list, and possible charter.) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 07:49:56 -0000 Just to add some reading material to the mailing list archive... You may want to read: New I-D by Jakob, Paul, Warren and Adam: http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-00.txt Slightly older CERT RR (which we already have): http://tools.ietf.org/html/rfc4398 And various older proposals which didn't make it: (Jakob's) http://stupid.domain.name/ietf/draft-schlyter-pkix-dns-02.txt (RR TYPE request I did) http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00421.html This is just to summarize the ideas which were floating around for some time. The basis on our work will be in the most recent I-D. On 17.8.2010 19:21, Warren Kumari wrote: > Hello all, > > We are investigating starting a working group to leverage the DNSSEC > trust anchor as a trust anchor for various other protocols. We are > initially focusing on TLS, but are also interested in other > protocols. > > Just so that we are all level set, here is our initial (draft) > problem statement. > > Problem Statement: > > The DNS Security Extensions are a collection of resource records and > protocol modifications that provide source authentication for the > DNS. > > The DNSSEC signed root infrastructure provides a single, well > published trust-anchor and a method to build a chain of trust from an > individual resource record (RR) to that TA. By leveraging this > infrastructure we can securely bind information (such as a public > key, certificate identifier, etc) to a DNS name. > > Increasingly people would like to be able to take advantage of the > confidentiality and identity validation provided by protocols such as > TLS. There are numerous barriers to this, including cost, ease of > use, complexity, certificate management, etc. By allowing users to > securely publish public key information we can allow users to easily > and securely make use of self-signed certificates. > > Currently, one of the issues limiting the use of self-signed > certificates is the difficulty in key-distribution - it is infeasible > to distribute a key binding at the web scale. By providing a means to > publish (and securely validate) this information in the DNS, we allow > for users to attest to the validity of keying information and > establish trust in the published public key. > > The DNSSEC root trust anchor can also be used for additional > validation during the current path validations. By validating that > the certificate presented is the certificate identified by the DNS, > we can provide additional confidence that the client is connecting to > the intended server - this helps alleviate concerns that a valid > certificate has been obtained by an attacker (for example from a CA > not used by the victim). -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@ietf.org Delivered-To: keyassure@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id CF0433A6807; Tue, 17 Aug 2010 11:36:02 -0700 (PDT) From: IETF Secretariat To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100817183602.CF0433A6807@core3.amsl.com> Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT) Cc: keyassure@ietf.org Subject: [keyassure] New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 18:36:03 -0000 A new IETF non-working group email list has been created. List address: keyassure@ietf.org Archive: http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/keyassure Description: This list is for discussion relating to using DNSSEC-protected DNS queries to get greater assurance for keys and certificates that are passed in existing IETF protocols. The main idea is that a relying party can get additional information about a domain name to eliminate the need for using a certificate in a protocol, to eliminate the need for sending certificates in the protocol if they are optional, and/or to assure that the certificate given in a protocol is associated with the domain name used by the application. In all three cases, the application associates the key or key fingerprint securely retrieved from the DNS with the domain name that was used in the DNS query. For additional information, please contact the list administrators. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17F23A6804 for ; Tue, 17 Aug 2010 10:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3Gyd+W-p5+p for ; Tue, 17 Aug 2010 10:21:17 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id DEF673A63C9 for ; Tue, 17 Aug 2010 10:21:14 -0700 (PDT) Received: from dhcp-172-29-46-185.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 4859D22848F6; Tue, 17 Aug 2010 13:20:29 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Aug 2010 13:21:49 -0400 Message-Id: To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [keyassure] Welcome to the mailing list, and possible charter. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 17:21:18 -0000 Hello all,=20 We are investigating starting a working group to leverage the DNSSEC = trust anchor as a trust anchor for various other protocols. We are = initially focusing on TLS, but are also interested in other protocols. Just so that we are all level set, here is our initial (draft) problem = statement. Problem Statement: The DNS Security Extensions are a collection of resource records and = protocol modifications that provide source authentication for the DNS. The DNSSEC signed root infrastructure provides a single, well published = trust-anchor and a method to build a chain of trust from an individual = resource record (RR) to that TA. By leveraging this infrastructure we = can securely bind information (such as a public key, certificate = identifier, etc) to a DNS name. Increasingly people would like to be able to take advantage of the = confidentiality and identity validation provided by protocols such as = TLS. There are numerous barriers to this, including cost, ease of use, = complexity, certificate management, etc. By allowing users to securely = publish public key information we can allow users to easily and securely = make use of self-signed certificates. Currently, one of the issues limiting the use of self-signed = certificates is the difficulty in key-distribution - it is infeasible to = distribute a key binding at the web scale. By providing a means to = publish (and securely validate) this information in the DNS, we allow = for users to attest to the validity of keying information and establish = trust in the published public key. The DNSSEC root trust anchor can also be used for additional validation = during the current path validations. By validating that the certificate = presented is the certificate identified by the DNS, we can provide = additional confidence that the client is connecting to the intended = server - this helps alleviate concerns that a valid certificate has been = obtained by an attacker (for example from a CA not used by the victim). Warren=