From benl@google.com Fri Oct 1 09:02:05 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9773A6EE1 for ; Fri, 1 Oct 2010 09:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.814 X-Spam-Level: X-Spam-Status: No, score=-105.814 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 QIIMhTdxtfZN for ; Fri, 1 Oct 2010 09:02:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 695533A6F0E for ; Fri, 1 Oct 2010 09:02:04 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o91G2oAM007611 for ; Fri, 1 Oct 2010 09:02:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1285948970; bh=Aa/RDet4U4g3X8+ZMLQN3AoQASc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=k7A7MLoGYCRj2dOs0YTXkUhslBZ6YSdjkmMNGZUukNovhq6sdHP6u4hBM8YBCwypf 7ACetHSa0FxUZGR596p2Q== Received: from pxi5 (pxi5.prod.google.com [10.243.27.5]) by wpaz1.hot.corp.google.com with ESMTP id o91G21ec026289 for ; Fri, 1 Oct 2010 09:02:49 -0700 Received: by pxi5 with SMTP id 5so1098875pxi.26 for ; Fri, 01 Oct 2010 09:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Olt8dUkfKx3LoGn2vUk46zoSpguWEU2T72pWkvptLvg=; b=kN0EX4Le2lEV9LDymF1I0tXdoZ1Ua9fC911Y4CpC2NEsU5w2ucoL/4pWkUgARak/Dv OYUdM9lAhDAVuCV5IkKQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ebcAkBv+O0WHk6UdDmP7gWKibvGauUn2vuyLLGm6DfViMN/hJ8tvSg/f9niDR7KC5P me6812QjS0Fr7EOyWwAw== MIME-Version: 1.0 Received: by 10.114.36.18 with SMTP id j18mr6526823waj.46.1285948969155; Fri, 01 Oct 2010 09:02:49 -0700 (PDT) Received: by 10.220.201.9 with HTTP; Fri, 1 Oct 2010 09:02:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Oct 2010 09:02:48 -0700 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 16:02:05 -0000 On 1 October 2010 08:29, Phillip Hallam-Baker wrote: > The reason that I started with the requirement to use SSL is that security > policy relating to trust criteria is meaningless until you have a statement > that use of SSL is required. I can't agree with this. If a user types an https URL, say, then there's every reason security policy should apply despite the lack of a statement that SSL is required. > I have no objection to doing security policy. But I do have a real objection > to an approach that negates PKIX semantics as the TLSFP approach does. Then I'd like to see your proposal for _optionally_ allowing PKIX to be overridden. From turners@ieca.com Fri Oct 1 15:03:23 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CB713A6CC9 for ; Fri, 1 Oct 2010 15:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.035 X-Spam-Level: X-Spam-Status: No, score=-102.035 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 Mc-zkoCeIJ9h for ; Fri, 1 Oct 2010 15:03:22 -0700 (PDT) Received: from smtp112.biz.mail.sp1.yahoo.com (smtp112.biz.mail.sp1.yahoo.com [69.147.92.225]) by core3.amsl.com (Postfix) with SMTP id 8A5A13A6B53 for ; Fri, 1 Oct 2010 15:03:22 -0700 (PDT) Received: (qmail 73902 invoked from network); 1 Oct 2010 22:04:09 -0000 Received: from thunderfish.local (turners@96.241.11.195 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 01 Oct 2010 15:04:08 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 851r6VUVM1mwTzKqAfVv4nWmWa9CU9KFyd2XDkXa7lVBR8Z fmH9jLYXL5dJuI1Tb.Jr7.EUH5cbrjbRZFNorrBx3cEZe4ilfaERRN8UZ3u2 AmFOnazmHzilDY6RUytneRDB50NG8me1.t_EhpyHbLoQi.O39DXsVXbBwSFC yRYgKLjEhhDYlzNUlEann7uRd5mvqK8gz1SnHnI3TA6fhxh8XA2Gf6wGmQ7u L7k.ihxjBUrH7Vd2Q_BWYcDvs3vmfQwrAWXCdE6epkhdWc1twNrXqRal1Zt2 qD3KddlbPH9AENozsD_JhwAei7j03Fb.eu3xC9id5Dsjh.4yoMt.6sQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CA65AD7.80300@ieca.com> Date: Fri, 01 Oct 2010 18:04:07 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org, cfrg@irtf.org Content-Type: multipart/mixed; boundary="------------010709000501030705040703" Subject: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 22:03:23 -0000 This is a multi-part message in MIME format. --------------010709000501030705040703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit While writing an update for the MD2, MD4, and MD5 security considerations, somebody pointed out that we should do the same for SHA-1. We ended up doing SHA-0 too. Below is a link to the draft. Please send comments to saag/cfrg. spt -------- Original Message -------- Subject: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt Date: Fri, 1 Oct 2010 13:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms Author(s) : T. Polk, S. Turner, L. Chen Filename : draft-turner-sha0-sha1-seccon-00.txt Pages : 7 Date : 2010-10-1 This document updates the security considerations for the SHA-1 message digest algorithm. Additionally, it discusses security considerations for the SHA-0 message digest algorithm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-sha0-sha1-seccon-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------010709000501030705040703 Content-Type: Message/External-body; name="draft-turner-sha0-sha1-seccon-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-turner-sha0-sha1-seccon-00.txt" Content-Type: text/plain Content-ID: <2010-10-1132831.I-D@ietf.org> --------------010709000501030705040703 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------010709000501030705040703-- From paul.hoffman@vpnc.org Sat Oct 2 09:24:53 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1893A6C6E; Sat, 2 Oct 2010 09:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.389 X-Spam-Level: X-Spam-Status: No, score=-101.389 tagged_above=-999 required=5 tests=[AWL=0.657, 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 epQx97yy5gYb; Sat, 2 Oct 2010 09:24:52 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 12D3E3A6C5B; Sat, 2 Oct 2010 09:24:52 -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 o92GPfjO098045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Oct 2010 09:25:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4CA65AD7.80300@ieca.com> References: <4CA65AD7.80300@ieca.com> Date: Sat, 2 Oct 2010 09:25:25 -0700 To: saag@ietf.org, cfrg@irtf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 16:24:53 -0000 At 6:04 PM -0400 10/1/10, Sean Turner wrote: >While writing an update for the MD2, MD4, and MD5 security considerations, somebody pointed out that we should do the same for SHA-1. We ended up doing SHA-0 too. Below is a link to the draft. Please send comments to saag/cfrg. 4. Guidance SHA-1 no longer provides an acceptable security level when used in digital signature applications. IETF protocol designers SHOULD NOT specify digital signature algorithms using SHA-1 as mandatory to implement. IETF protocols that rely on SHA-1 based digital signatures MUST include countermeasures that mitigate SHA-1's reduced collision resistance by randomized hashing (e.g., as specified in [SP800-107]). HMAC-SHA-1 remains secure and is the preferred keyed hash algorithm for IETF protocol design. As noted above, any use of SHA-0 is strongly discouraged. Discussions regarding the strength of SHA-0 were included for completeness only. SHA-0 has no functional or performance advantage, and SHA-1 is considered significantly more secure. There are many serious issues here. First the procedural ones. - It is not "guidance" if you use "MUST": it is a mandate. In this case, it is not clear why the authors get to make a mandate on IETF protocol designers. If it is because two of the authors are Security ADs, the document should say so explicitly (although then you have to explain why you dragged Lily into it). If it is because two of the authors are from NIST, the document should say so explicitly (although then you have to explain why you dragged Sean into it). - The "SHOULD NOT" in the first paragraph does not say when it is OK to do so anyway, so this goes against RFC 2119. - There is no explanation of why an Informational RFC have any effect on IETF standards-track documents. Next the security issues. - The first sentence is obviously wrong unless you believe that >95% of all financial transaction in the world today are insecure. This type of hyperbole does not belong in IETF documents. - The third sentence, on randomized hashing, is not based on reality. Few if any of the current IETF protocols show how to carry the random number used. This sentence essentially says "all IETF protocols must use an unspecified protocol". - The third paragraph makes it sound like there is a security problem that needs to be solved, but there isn't. A quick search shows that exactly two RFCs even mention SHA-0, and neither RFC is a protocol. If the authors really did mean to give useful guidance, I propose the following replacement for this section: ===== SHA-1 provides less collision resistance than was originally expected, and collision resistance has been shown to affect some (but not all) applications that use digital signatures. Even if SHA-1's collision resistance was as good as was expected, SHA-256's collision resistance and resistance to finding pre-images are much higher by design. Because of this, designers of IETF protocols should put a strong preference for signature algorithms with SHA-256 in their protocols. The typical way to give such a preference is to make the algorithm that uses SHA-256 mandatory, while the algorithm using SHA-1 being optional. Of course, SHA-0 should continue to not be used in any IETF protocol. Nearly all IETF protocols that use signatures assume existing public key infrastructures, and SHA-1 is still used in signatures nearly everywhere. Therefore, it is unwise to prohibit the use of SHA-1 in signature algorithms. However, it is certainly useful to point out in the security considerations for those protocols that SHA-1 is not as strong as SHA-256. A protocol designer might want to consider the use of SHA-1 with randomized hashing such as is specified in [SP800-107]. However, such use will still not be stronger than the normal use of SHA-256, and it expands the size of signatures and requires them to carry material that is not needed today. HMAC-SHA-1 remains secure and is the preferred keyed hash algorithm for IETF protocol design. ===== You can then remove the reference to RFC 2119. --Paul Hoffman, Director --VPN Consortium From benl@google.com Sat Oct 2 13:15:35 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4C23A6DB7 for ; Sat, 2 Oct 2010 13:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.832 X-Spam-Level: X-Spam-Status: No, score=-105.832 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 rI2BldZb-U3Q for ; Sat, 2 Oct 2010 13:15:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 0EB363A6DB4 for ; Sat, 2 Oct 2010 13:15:31 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o92KGMu9003066 for ; Sat, 2 Oct 2010 13:16:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1286050583; bh=6uuXUB620KGg3G9vDpjHVr+22Cs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ExxxdZm9FDRowNqzBbDJUL+pxfmyA16ChL5x68oB0iaoI5Cyj2YpFcEfez7LkpWTw l65b7D+r182X+qTlsbKOA== Received: from qyk4 (qyk4.prod.google.com [10.241.83.132]) by wpaz5.hot.corp.google.com with ESMTP id o92KGJbI017611 for ; Sat, 2 Oct 2010 13:16:22 -0700 Received: by qyk4 with SMTP id 4so2904041qyk.2 for ; Sat, 02 Oct 2010 13:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9Iqtx4pY1xBVXOqA3BdW5X8NS6INnk5huWdQ+OUdxr4=; b=vRWovD8LpQIK1iqKcCW/TbDco/9RkozYPs1F93ten8Vufy5iIgh7u+AqQ+P4sYXJAB VfV4Tw4w9VSfsiEoc3rA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oC+jvEs+1m+3tBbQ1gL8oNeyCVUvyTHzI7Y/1j9HSSrkJO6REHLDZdJFaOHOvrDbuG MDxhSOd9XsLmmnKoaPHQ== MIME-Version: 1.0 Received: by 10.220.34.142 with SMTP id l14mr1873460vcd.83.1286050579493; Sat, 02 Oct 2010 13:16:19 -0700 (PDT) Received: by 10.220.201.9 with HTTP; Sat, 2 Oct 2010 13:16:19 -0700 (PDT) In-Reply-To: References: <1285970705.1984.136.camel@mattlaptop2.local> Date: Sat, 2 Oct 2010 13:16:19 -0700 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Matt McCutchen , dnsop@ietf.org, saag@ietf.org, tls@ietf.org, pkix@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 20:15:35 -0000 On 1 October 2010 16:15, Phillip Hallam-Baker wrote: > > > On Fri, Oct 1, 2010 at 6:05 PM, Matt McCutchen > wrote: >> >> On Fri, 2010-10-01 at 11:29 -0400, Phillip Hallam-Baker wrote: >> > In particular I am very concerned about the particular approach being >> > taken to security policy. What the proposers are attempting to do is >> > to create a mechanism that allows a site that only uses one particular >> > high assurance CA to 'protect' themselves against SSL certificates >> > being issued by low assurance CAs. >> > >> > As such, this is an objective I approve of and is one that I would >> > like to see supported in a generalized security policy. It should be >> > possible for a site to make security policy statements of the form >> > 'all valid PKIX certs for example.com have cert X in the validation >> > path'. >> > >> > What I object to is the approach being taken which is to use DNSSEC to >> > replace PKIX certificate validation entirely. >> >> Realize that I, and I would guess many other site admins, want precisely >> that. =A0PKIX is complicated, whereas once I have a DNSSEC signed zone, >> placing my TLS server's certificate in the zone and knowing that clients >> will accept that certificate and no other could hardly be simpler. =A0An= d >> why shouldn't I be allowed to do it? =A0I have complete authority over m= y >> zone (even for the most part in the present public CA system). =A0Nobody >> gave PKIX a monopoly on the determination of certificate acceptability. >> >> We could support a more general scheme in which positive assurance is >> separate from restrictions, but don't be surprised when a significant >> fraction of sites use it to effectively "replace PKIX certificate >> validation". >> > > The problem with that approach is that the attacker now has two > infrastructures that they can attack rather than just one. If I deploy the DNS solution, stating that DNS is authoritative, then my attack surface now excludes all CAs. How is that an increase in attack surface? Contrast with today's situation, where my attack surface is increased on a regular basis by the introduction of new CAs, without any consultation with me at all. > You are increasing your attack surface, not reducing and simplifying it a= s > you might imagine. > >> >> > Worse still, the proponents refuse to allow any method of shutting >> > this system off. So if I have a site where I want to use DNSSEC >> > validated certificates on the mail server, deployment is going to >> > impact my Web server. >> >> Yes, there should be a way to make the exclusivity optional, but there >> may be better ways to solve the problem you cited, such as placing the >> DNSSEC certificate at the SRVName for the mail server. > > > Regardless, I believe that the PKIX and TLS groups should be aware that t= his > is the change that has been implemented in code and is being proposed bef= ore > the WG is chartered. > There are much better ways to express the trust restriction semantics. I = do > not see why the ability to express statements concerning your trust roots > needs to require deployment of a completely different mechanism and trust > path for the end entity keys. > > For example, the ESRV mechanism is extensible. So it is possible for a si= te > that has their own PKI and root of trust to specify that there has to be = a > trust path that includes that root of trust. Or you could publish a > fingerprint of a cross cert that has to be involved or you could even sta= te > that there must be a cert record with the right fingerprint. > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From mouse@Sparkle.Rodents-Montreal.ORG Sat Oct 2 17:52:54 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888FA3A6DFA; Sat, 2 Oct 2010 17:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.15 X-Spam-Level: X-Spam-Status: No, score=-7.15 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXtgA45eZ8+4; Sat, 2 Oct 2010 17:52:53 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 568313A6DED; Sat, 2 Oct 2010 17:52:53 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id UAA12197; Sat, 2 Oct 2010 20:53:30 -0400 (EDT) Date: Sat, 2 Oct 2010 20:53:30 -0400 (EDT) From: der Mouse Message-Id: <201010030053.UAA12197@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sat, 2 Oct 2010 20:46:00 -0400 (EDT) To: saag@ietf.org, cfrg@irtf.org In-Reply-To: References: <4CA65AD7.80300@ieca.com> Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 00:52:54 -0000 > - The third sentence, on randomized hashing, is not based on reality. > Few if any of the current IETF protocols show how to carry the random > number used. This is not necessarily a reason not to use randomized hashes; the random number could, for example, be prepended to the "real" hash. > This sentence essentially says "all IETF protocols must use an > unspecified protocol". This, however, is valid...absent a standardized way to package the random number together with the "real" hash, at least. > [proposed alternative text] > Even if SHA-1's collision resistance was as good as was expected, While I realize the subjunctive is on its way out in English, there's no need to hurry the process, and there are still people, like me, who have a little internal voice piping up saying something uncomplimentary about the literacy level of the author upon seeing something like this. You might want to fix it, if only to avoid the negative emotional colour it provokes in some readers. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From pgut001@cs.auckland.ac.nz Sat Oct 2 21:13:20 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D7A3A6CC3; Sat, 2 Oct 2010 21:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.423 X-Spam-Level: X-Spam-Status: No, score=-3.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVgnXRAKWe6t; Sat, 2 Oct 2010 21:13:17 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id F34743A6CBA; Sat, 2 Oct 2010 21:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1286079250; x=1317615250; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hallam@gmail.com,=20marsh@extendedsubset.com |Subject:=20Re:=20[pkix]=20[TLS]=20=20Cert=20Enumeration =20and=20Key=20Assurance=20With=20DNSSEC|Cc:=20benl@googl e.com,=20dnsop@ietf.org,=20pkix@ietf.org,=20saag@ietf.org ,=0D=0A=20=20=20=20tls@ietf.org|In-Reply-To:=20 |Message-Id:=20|Date:=20Sun,=2003=20Oct=202010=2017:14:06=20+130 0; bh=T3vmDS0FinxYWvomixy3afWZwpCIHxwHJgqJNNNc46I=; b=PQMaKsEz+teqejsdUVJPkBgPezRaV6cELAOdxDOnoywHZKZ0GtN/xZ3r 86DiPN5GzlRNtLHwg2hjZpQXI5rKNyAQWhig3v7F1zkFJmFKOrFbD6Cbi f9eWjA6dJocxRZN34AEvoJYPQ8nD2HNo03dp3FX+O6mT21ej0g7SUpxtM o=; X-IronPort-AV: E=Sophos;i="4.57,273,1283688000"; d="scan'208";a="29379051" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Oct 2010 17:14:06 +1300 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1P2Fxe-0007zZ-C6; Sun, 03 Oct 2010 17:14:06 +1300 From: Peter Gutmann To: hallam@gmail.com, marsh@extendedsubset.com In-Reply-To: Message-Id: Date: Sun, 03 Oct 2010 17:14:06 +1300 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 04:13:20 -0000 Phillip Hallam-Baker writes: >The attack surface is the number of paths that are open to an attacker. > >In the current model there is only one trust path, the PKIX path. Which isn't so much a path as a twelve-lane motorway with elevated cloverleaf interchanges, twenty-four-hour drive-through catering stops, and large neon signs every few km inviting every attacker to join in. >In the new model, the attacker has a choice of trust paths, the PKIX path and >the DNSSEC path and they can attack either of them. Or you can block off the PKIX motorway and leave only the (possibly) smaller DNSSEC two-lane road. (I'm not sure whether DNSSEC has a smaller overall attack surface than PKIX, but chances are it does because the only security protocol with an even larger attack surface than PKIX is XMLsec, whose attack surface is so huge that it won't fit on the planets surface but actually extends several km out into space). Peter. From tobias.gondrom@gondrom.org Sun Oct 3 13:49:36 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E6B3A6DC1 for ; Sun, 3 Oct 2010 13:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.969 X-Spam-Level: X-Spam-Status: No, score=-94.969 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, 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 kkBS1utSt3Up for ; Sun, 3 Oct 2010 13:49:35 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 804003A6D97 for ; Sun, 3 Oct 2010 13:49:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=WDYBuTWQsOAmrcHDZ3Qo7xB/Zg0NY+JHyjIj96aoJvLVevlvRQnJpGFzP2rvSTb69310eTz7gjmH+cWHkW39mO2ctmAP6pD7oyZC1S81J8rUI/3tWVOrekcjQUETQJH2; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 18249 invoked from network); 3 Oct 2010 22:49:38 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Oct 2010 22:49:38 +0200 Message-ID: <4CA8ECA9.9020201@gondrom.org> Date: Sun, 03 Oct 2010 21:50:49 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100914 SUSE/3.1.4 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: saag@ietf.org X-Priority: 4 (Low) References: <4CA65AD7.80300@ieca.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: cfrg@irtf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 20:49:36 -0000 Must say I agree with Paul's concerns below (and in particular hesitated too when I read the intended "MUST NOT" effect of a guidance informational draft on standards documents). However, I think the general idea to write a guidance ID is a good idea from Tim, et al. One further comment: I am a bit uncertain to why you refer to SHA-256 from the SHA-2 family only (and thus not mention/exclude SHA-512)? Tobias On 10/02/2010 05:25 PM, Paul Hoffman wrote: > At 6:04 PM -0400 10/1/10, Sean Turner wrote: >> While writing an update for the MD2, MD4, and MD5 security considerations, somebody pointed out that we should do the same for SHA-1. We ended up doing SHA-0 too. Below is a link to the draft. Please send comments to saag/cfrg. > 4. Guidance > > SHA-1 no longer provides an acceptable security level when used in > digital signature applications. IETF protocol designers SHOULD NOT > specify digital signature algorithms using SHA-1 as mandatory to > implement. IETF protocols that rely on SHA-1 based digital > signatures MUST include countermeasures that mitigate SHA-1's reduced > collision resistance by randomized hashing (e.g., as specified in > [SP800-107]). > > HMAC-SHA-1 remains secure and is the preferred keyed hash algorithm > for IETF protocol design. > > As noted above, any use of SHA-0 is strongly discouraged. Discussions > regarding the strength of SHA-0 were included for completeness only. > SHA-0 has no functional or performance advantage, and SHA-1 is > considered significantly more secure. > > There are many serious issues here. First the procedural ones. > > - It is not "guidance" if you use "MUST": it is a mandate. In this case, it is not clear why the authors get to make a mandate on IETF protocol designers. If it is because two of the authors are Security ADs, the document should say so explicitly (although then you have to explain why you dragged Lily into it). If it is because two of the authors are from NIST, the document should say so explicitly (although then you have to explain why you dragged Sean into it). > > - The "SHOULD NOT" in the first paragraph does not say when it is OK to do so anyway, so this goes against RFC 2119. > > - There is no explanation of why an Informational RFC have any effect on IETF standards-track documents. > > Next the security issues. > > - The first sentence is obviously wrong unless you believe that >95% of all financial transaction in the world today are insecure. This type of hyperbole does not belong in IETF documents. > > - The third sentence, on randomized hashing, is not based on reality. Few if any of the current IETF protocols show how to carry the random number used. This sentence essentially says "all IETF protocols must use an unspecified protocol". > > - The third paragraph makes it sound like there is a security problem that needs to be solved, but there isn't. A quick search shows that exactly two RFCs even mention SHA-0, and neither RFC is a protocol. > > If the authors really did mean to give useful guidance, I propose the following replacement for this section: > > ===== > SHA-1 provides less collision resistance than was originally > expected, and collision resistance has been shown to affect some (but > not all) applications that use digital signatures. Even if SHA-1's > collision resistance was as good as was expected, SHA-256's collision > resistance and resistance to finding pre-images are much higher by > design. > > Because of this, designers of IETF protocols should put a strong > preference for signature algorithms with SHA-256 in their protocols. > The typical way to give such a preference is to make the algorithm > that uses SHA-256 mandatory, while the algorithm using SHA-1 being > optional. Of course, SHA-0 should continue to not be used in any IETF > protocol. > > Nearly all IETF protocols that use signatures assume existing public > key infrastructures, and SHA-1 is still used in signatures nearly > everywhere. Therefore, it is unwise to prohibit the use of SHA-1 in > signature algorithms. However, it is certainly useful to point out in > the security considerations for those protocols that SHA-1 is not as > strong as SHA-256. > > A protocol designer might want to consider the use of SHA-1 with > randomized hashing such as is specified in [SP800-107]. However, such > use will still not be stronger than the normal use of SHA-256, and it > expands the size of signatures and requires them to carry material > that is not needed today. > > HMAC-SHA-1 remains secure and is the preferred keyed hash algorithm > for IETF protocol design. > ===== > > You can then remove the reference to RFC 2119. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From paul.hoffman@vpnc.org Sun Oct 3 14:34:37 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711703A6E8E; Sun, 3 Oct 2010 14:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=0.654, 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 me0PImaSIdw8; Sun, 3 Oct 2010 14:34:36 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2FF523A6E1A; Sun, 3 Oct 2010 14:34:35 -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 o93LZOx1059883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Oct 2010 14:35:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4CA8ECA9.9020201@gondrom.org> References: <4CA65AD7.80300@ieca.com> <4CA8ECA9.9020201@gondrom.org> X-Priority: 4 (Low) Date: Sun, 3 Oct 2010 14:35:23 -0700 To: Tobias Gondrom From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 21:34:37 -0000 At 9:50 PM +0100 10/3/10, Tobias Gondrom wrote: > Must say I agree with Paul's concerns below (and in particular >hesitated too when I read the intended "MUST NOT" effect of a guidance >informational draft on standards documents). >However, I think the general idea to write a guidance ID is a good idea >from Tim, et al. Fully agree (certainly more useful than such guidance coming from you or I). However, it would be nice if the document said why they were the ones writing it. >One further comment: I am a bit uncertain to why you refer to SHA-256 >from the SHA-2 family only (and thus not mention/exclude SHA-512)? Because the IETF almost always deals only with 128-bit strength security, and using SHA-384 or SHA-512 is just as waste of processor and network resources in such cases. --Paul Hoffman, Director --VPN Consortium From simon@josefsson.org Mon Oct 4 02:02:09 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8EB3A6F6C; Mon, 4 Oct 2010 02:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.665 X-Spam-Level: X-Spam-Status: No, score=-102.665 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 xS8jjc2aTVU9; Mon, 4 Oct 2010 02:02:09 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id BC0183A6F56; Mon, 4 Oct 2010 02:02:08 -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 o9492vwJ018716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Oct 2010 11:02:59 +0200 From: Simon Josefsson To: Paul Hoffman References: <4CA65AD7.80300@ieca.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:101004:cfrg@irtf.org::M9gO9Ed2UAfpEUGI:CFF+ X-Hashcash: 1:22:101004:paul.hoffman@vpnc.org::oQYW1l5ytAav2xuw:8hSf X-Hashcash: 1:22:101004:saag@ietf.org::YR0OBXhmrQLaG2Yr:XWUy Date: Mon, 04 Oct 2010 11:02:55 +0200 In-Reply-To: (Paul Hoffman's message of "Sat\, 2 Oct 2010 09\:25\:25 -0700") Message-ID: <87k4lytjnk.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.3 at yxa-v X-Virus-Status: Clean Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 09:02:10 -0000 Paul Hoffman writes: > If the authors really did mean to give useful guidance, I propose the > following replacement for this section: Re-reading the original text and Paul's proposed text below, I strongly prefer the latter one. The situation is not as simple as the original text implies, and this needs to be conveyed by the document somehow. Avoiding RFC 2119 language, which doesn't make sense for an Informational document anyway, is a good way to achieve this. /Simon > ===== > SHA-1 provides less collision resistance than was originally > expected, and collision resistance has been shown to affect some (but > not all) applications that use digital signatures. Even if SHA-1's > collision resistance was as good as was expected, SHA-256's collision > resistance and resistance to finding pre-images are much higher by > design. > > Because of this, designers of IETF protocols should put a strong > preference for signature algorithms with SHA-256 in their protocols. > The typical way to give such a preference is to make the algorithm > that uses SHA-256 mandatory, while the algorithm using SHA-1 being > optional. Of course, SHA-0 should continue to not be used in any IETF > protocol. > > Nearly all IETF protocols that use signatures assume existing public > key infrastructures, and SHA-1 is still used in signatures nearly > everywhere. Therefore, it is unwise to prohibit the use of SHA-1 in > signature algorithms. However, it is certainly useful to point out in > the security considerations for those protocols that SHA-1 is not as > strong as SHA-256. > > A protocol designer might want to consider the use of SHA-1 with > randomized hashing such as is specified in [SP800-107]. However, such > use will still not be stronger than the normal use of SHA-256, and it > expands the size of signatures and requires them to carry material > that is not needed today. > > HMAC-SHA-1 remains secure and is the preferred keyed hash algorithm > for IETF protocol design. > ===== > > You can then remove the reference to RFC 2119. > > --Paul Hoffman, Director > --VPN Consortium From stephen.farrell@cs.tcd.ie Mon Oct 4 09:04:14 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB20F3A6FE8; Mon, 4 Oct 2010 09:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.813 X-Spam-Level: X-Spam-Status: No, score=-102.813 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 oDwLQErRl0ZP; Mon, 4 Oct 2010 09:04:13 -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 A04943A6FC9; Mon, 4 Oct 2010 09:04:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 619813E40F4; Mon, 4 Oct 2010 17:05:06 +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=1286208306; bh=9wi2BIw07IQ1bZ BPbnrLZGsxDFaCDfR8Fexn4QEEdZk=; b=kGrgV+/R4SEe+9zJ0tQwQvvz3rwVob oN3X5kr6fmryIRHU5BR8q0cc1sO8cuFD21a1vvsV9hAk8vIFnS9evoX8+j72erwH 5xPH/AEehECr9QGMjY67TeXS3kdn3fh7m+dyDnuogGpJ1E0v2Xsepe02v4EgZaKj YhOWOdxoMgCdi3Pk/GCtnwNWk5286RQNRIU1Xz9lm2Z7FRXmL8iW6W7RiuZ0fRxC RR0885M3I4rjiwCn5rFmD30PsfIwhBw8XieHEdmt/NOE+g+460InrKdrACBRqyOg gZaWV+RvUrhu+v7Hz6YLXx/P91RKJ2xt2TgdgyHGJVnuRQhR44pLwciw== 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 gzhax3g9s9lp; Mon, 4 Oct 2010 17:05:06 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D7DE63E40F0; Mon, 4 Oct 2010 17:05:05 +0100 (IST) Message-ID: <4CA9FB2F.4000300@cs.tcd.ie> Date: Mon, 04 Oct 2010 17:05:03 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: mrex@sap.com References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> In-Reply-To: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org, marsh@extendedsubset.com, saag@ietf.org, pkix@ietf.org, Phillip Hallam-Baker , tls@ietf.org Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:04:14 -0000 On 04/10/10 15:37, Martin Rex wrote: > One thing that needs to be addressed/solved is the key/cert rollover > for any TLS-Server, so that it is possible to list more than one > server cert as "valid" for a Server through DNS, at least for the > time of the transition/rollover. Maybe a side-issue here, but this came up in the W3C WSC work and I wrote up an idea for that (not based on DNS) which is RFC 5697. [1] No idea if anyone is using or would use it, though I did have a student implement it, so it *could* work. (Note: that's an experimental-track RFC, as it ought be:-) S. [1] http://tools.ietf.org/html/rfc5697 From ondrej.sury@nic.cz Mon Oct 4 09:28:44 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20273A6CAB; Mon, 4 Oct 2010 09:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=0.404, 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 JFC1rq1UnrrH; Mon, 4 Oct 2010 09:28:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id ECFE33A6D8A; Mon, 4 Oct 2010 09:28:41 -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 366D3734236; Mon, 4 Oct 2010 18:29:36 +0200 (CEST) Message-ID: <4CAA00EF.2040107@nic.cz> Date: Mon, 04 Oct 2010 18:29:35 +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.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: pkix@ietf.org, dnsop@ietf.org, tls@ietf.org, saag@ietf.org Subject: Re: [saag] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:28:44 -0000 Phillip, you present your views by cross-posting several other IETF mailing list without posting this to keyassure@ietf.org. This doesn't give potential readers full picture about what's happening in the keyassure and what is the general consensus in the list. So please all - if you want to respond to Phillip's message, first go to keyassure mailing list archive[1], then join the the list[2] and comment there. I don't think we want to fill our inboxes with this discussion (which should really happen in keyassure) in several copies. While we value input from other working groups it is already hard to follow the discussion in one mailing list and when it splits to many, it will be just a mess. Ondrej 1. http://www.ietf.org/mail-archive/web/keyassure/ 2. https://www.ietf.org/mailman/listinfo/keyassure On 1.10.2010 17:29, Phillip Hallam-Baker wrote: > For the past month I have been participating in the KEYASSURE discussions. > > One aspect of those discussions that was not made clear in the original > notice sent out is that the group is not only considering key assurance, > the proposals made are also intended to have security policy semantics. > > This was not apparent to me from reading the list announcement, the > initial proposed charter or the Internet drafts. I have asked the > organizers of the group to clarify the matter in the wider IETF > community but they have not done so. > > > In particular I am very concerned about the particular approach being > taken to security policy. What the proposers are attempting to do is to > create a mechanism that allows a site that only uses one particular high > assurance CA to 'protect' themselves against SSL certificates being > issued by low assurance CAs. > > As such, this is an objective I approve of and is one that I would like > to see supported in a generalized security policy. It should be possible > for a site to make security policy statements of the form 'all valid > PKIX certs for example.com have cert X in the > validation path'. > > > What I object to is the approach being taken which is to use DNSSEC to > replace PKIX certificate validation entirely. > > Now the proponents are trying to downplay this by saying that 'all' they > are doing is to tell people to 'ignore' PKIX validation. But that > approach really offends my sense of layering. > > Worse still, the proponents refuse to allow any method of shutting this > system off. So if I have a site where I want to use DNSSEC validated > certificates on the mail server, deployment is going to impact my Web > server. > > > Specifically the proposal amounts to using the DNS CERT record to > publish a fingerprint of all the certificates permitted for use with TLS > at a specific domain: > > example.com CERT TLSFP 0 0 > example.com CERT TLSFP 0 0 > > It is proposed to replace current TLS certificate processing semantics > with the following: > > 1) Query for CERT record at example.com > 2) If no CERT record with TLSFP certificate type exists then perform > normal PKIX validation and return that result > 3) Otherwise attempt to match the TLS end entity certificate with one of > the fingerprints specified in the published TLSFP RRs > 4) If a match is found return VALID, otherwise return INVALID > > Note here that if there is a TLSFP RR that it takes precedence over PKIX > processing rules. > > There should of course be DNSSEC validation performed in that process as > well, but the authors have not explained how that is meant to work in > the context of their proposal so I left it out. > > > The defenses made for this approach are of the form 'you have to wear > big pants to play this game'. In other words if people are going to > administer these systems and not be burned they are going to have to > understand what they are doing. I do not consider this a responsible > approach to protocol design. > > What I would prefer is to have systems that do not need to be > administered by people at all. That is not possible when the approach > has hidden side effects that cannot be anticipated by scripts. > > > I am very much committed to the idea of doing security policy. But this > is not an approach I can support. Any policy mechanism has to be > orthogonal to the key validation strategy in my view. I should be able > to use any DNS security policy mechanism that the IETF endorses with > PKIX certificate processing semantics. > > I have proposed an alternative approach in > > http://tools.ietf.org/html/draft-hallambaker-esrv-00 > > This does not currently contain a mechanism to express trust > restrictions but is designed to be extensible to support such. When I > proposed ESRV I was unaware that the KEYASSURE proposal was intended to > have a security policy aspect at all. It is still not made explicit in > their draft. > > > Using the revised version of ESRV I am currently writing, a security > policy of the form 'always use TLS with any protocol at example.com > ' would have the form: > > example.com ESRV "tls=required" > > A security policy that was specific to http would be expressed as: > > example.com ESRV "prefix=_http._tcp" > _http._tcp.example.com ESRV "tls=required" > > or > > example.com ESRV "prefix=*" > _http._tcp.example.com ESRV "tls=required" > > The reason for this change from the -00 version is that this approach > supports CNAMEs. > > > The reason that I started with the requirement to use SSL is that > security policy relating to trust criteria is meaningless until you have > a statement that use of SSL is required. > > > I have no objection to doing security policy. But I do have a real > objection to an approach that negates PKIX semantics as the TLSFP > approach does. > > > -------- Original Message -------- > Subject: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC > Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT) > From: IETF Secretariat > > To: IETF Announcement list > > CC: keyassure@ietf.org , > ondrej.sury@nic.cz , warren@kumari.net > > > 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. > > > -- > 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 > ------------------------------------------- > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > > > > -- > Website: http://hallambaker.com/ > -- 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 ------------------------------------------- From dharkins@lounge.org Mon Oct 4 10:50:43 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2F73A6FF9 for ; Mon, 4 Oct 2010 10:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.711 X-Spam-Level: X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 eYmyBBEWD+op for ; Mon, 4 Oct 2010 10:50:42 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 636843A6FEF for ; Mon, 4 Oct 2010 10:50:42 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 426981E00BA; Mon, 4 Oct 2010 10:51:38 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 4 Oct 2010 10:51:38 -0700 (PDT) Message-ID: <092405dc28038119878c75f1b01f29bc.squirrel@www.trepanning.net> In-Reply-To: References: <4CA65AD7.80300@ieca.com> <4CA8ECA9.9020201@gondrom.org> Date: Mon, 4 Oct 2010 10:51:38 -0700 (PDT) From: "Dan Harkins" To: "Paul Hoffman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 1 (Highest) Importance: High Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 17:50:43 -0000 On Sun, October 3, 2010 2:35 pm, Paul Hoffman wrote: >>One further comment: I am a bit uncertain to why you refer to SHA-256 >>from the SHA-2 family only (and thus not mention/exclude SHA-512)? > > Because the IETF almost always deals only with 128-bit strength security, > and using SHA-384 or SHA-512 is just as waste of processor and network > resources in such cases. That's an odd statement. There is suite B guidance for use of quite alot of IETF protocols-- TLS, SSH, IKE/IPsec, S/MIME-- that provide for more than "128-bit strength security". The qualifier ("almost always") even adds to the oddness. Check out the D-H groups for use in IKE. They run the gamut of strength estimates. Arguably neither of the cryptographic suites for IPsec from RFC 4308, of which you are the author, provides 128-bits of strength security (the required D-H groups afford approximately 80 to "VPN-A" and 112 bits to "VPN-B"). We continue to define the use of ciphers with > 128 bit keys. We continue to define the use of D-H groups that produce shared secrets of > 128 bits of approximate strength. Hash algorithms that can be used in key derivation, key confirmation, and digital signatures which afford greater than 128-bits of approximate strength should not be excluded. Dan. From paul.hoffman@vpnc.org Mon Oct 4 11:12:26 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C26C3A7051; Mon, 4 Oct 2010 11:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.394 X-Spam-Level: X-Spam-Status: No, score=-101.394 tagged_above=-999 required=5 tests=[AWL=0.652, 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 9JnrzA2ppgf3; Mon, 4 Oct 2010 11:12:25 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3D9993A6FEE; Mon, 4 Oct 2010 11:12:25 -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 o94IDGrd014555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Oct 2010 11:13:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <092405dc28038119878c75f1b01f29bc.squirrel@www.trepanning.net> References: <4CA65AD7.80300@ieca.com> <4CA8ECA9.9020201@gondrom.org> <092405dc28038119878c75f1b01f29bc.squirrel@www.trepanning.net> X-Priority: 1 (Highest) Date: Mon, 4 Oct 2010 11:13:15 -0700 To: "Dan Harkins" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 18:12:26 -0000 At 10:51 AM -0700 10/4/10, Dan Harkins wrote: >On Sun, October 3, 2010 2:35 pm, Paul Hoffman wrote: >>>One further comment: I am a bit uncertain to why you refer to SHA-256 >>>from the SHA-2 family only (and thus not mention/exclude SHA-512)? >> >> Because the IETF almost always deals only with 128-bit strength security, >> and using SHA-384 or SHA-512 is just as waste of processor and network >> resources in such cases. > > That's an odd statement. There is suite B guidance for use of quite alot >of IETF protocols-- TLS, SSH, IKE/IPsec, S/MIME-- that provide for more >than "128-bit strength security". The qualifier ("almost always") even adds >to the oddness. Check out the D-H groups for use in IKE. They run the gamut >of strength estimates. Arguably neither of the cryptographic suites for >IPsec from RFC 4308, of which you are the author, provides 128-bits of >strength security (the required D-H groups afford approximately 80 to >"VPN-A" and 112 bits to "VPN-B"). Right; this my purposeful vagueness above. > We continue to define the use of ciphers with > 128 bit keys. We >continue to define the use of D-H groups that produce shared secrets >of > 128 bits of approximate strength. Hash algorithms that can be used >in key derivation, key confirmation, and digital signatures which afford >greater than 128-bits of approximate strength should not be excluded. All true, but not relevant to the text I gave. The draft as it stands *also* doesn't say what to do for signatures that are meant to be at strengths greater than 128 bits; it is about not using SHA-0 at all and not specifying SHA-1 as the default. If there is a desire for a different document that tells security protocol writers what signature algorithms would be good to include as mandatory, that's fine, but it should not be this document. --Paul Hoffman, Director --VPN Consortium From Nicolas.Williams@oracle.com Mon Oct 4 11:58:46 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DD03A7060; Mon, 4 Oct 2010 11:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 8lpxJscxiPub; Mon, 4 Oct 2010 11:58:45 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 2A94C3A7063; Mon, 4 Oct 2010 11:58:40 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o94IxWGh016410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Oct 2010 18:59:33 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o94IxUf2013761; Mon, 4 Oct 2010 18:59:31 GMT Received: from abhmt009.oracle.com by acsmt353.oracle.com with ESMTP id 661039901286218722; Mon, 04 Oct 2010 11:58:42 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Oct 2010 11:58:40 -0700 Date: Mon, 4 Oct 2010 13:58:33 -0500 From: Nicolas Williams To: Paul Hoffman Message-ID: <20101004185831.GJ9501@oracle.com> References: <4CA65AD7.80300@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 18:58:46 -0000 On Sat, Oct 02, 2010 at 09:25:25AM -0700, Paul Hoffman wrote: > - It is not "guidance" if you use "MUST": it is a mandate. In this > case, it is not clear why the authors get to make a mandate on IETF > protocol designers. [...] RFCs can impose mandates on protocol designers the same way that the U.S. Congress can pass laws that bind future Congresses. I.e., Congress can only pretend, but can't really bind future Congresses (or even the same Congress). But, so what? RFCs are the tool that we have for communicating such non-protocol matters as IETF process, so we might as well use them to "impose" mandates on protocol designers. > - There is no explanation of why an Informational RFC have any effect > on IETF standards-track documents. Even if it were a standards track RFC it still couldn't have any more effect on future standards-track RFCs than... the IESG and IETF are willing to enforce when reviewing future submissions. See above. Guidance such as this belongs in a BCP, if anything... For the rest, I mostly agree with Paul. Nico -- From jhutz@cmu.edu Mon Oct 4 14:44:12 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372F53A6D97; Mon, 4 Oct 2010 14:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 lrwdEtG41RaU; Mon, 4 Oct 2010 14:43:59 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id AE0063A6C9B; Mon, 4 Oct 2010 14:43:57 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o94Lip3Y021356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Oct 2010 17:44:51 -0400 (EDT) Date: Mon, 04 Oct 2010 17:44:51 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Paul Hoffman Message-ID: <9E4F286124541057D85563F1@minbar.fac.cs.cmu.edu> In-Reply-To: <1702_1286218784_o94IxhJi008577_20101004185831.GJ9501@oracle.com> References: <4CA65AD7.80300@ieca.com> <1702_1286218784_o94IxhJi008577_20101004185831.GJ9501@oracle.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 21:44:12 -0000 --On Monday, October 04, 2010 01:58:33 PM -0500 Nicolas Williams wrote: > On Sat, Oct 02, 2010 at 09:25:25AM -0700, Paul Hoffman wrote: >> - It is not "guidance" if you use "MUST": it is a mandate. In this >> case, it is not clear why the authors get to make a mandate on IETF >> protocol designers. [...] > > RFCs can impose mandates on protocol designers the same way that the > U.S. Congress can pass laws that bind future Congresses. I.e., Congress > can only pretend, but can't really bind future Congresses (or even the > same Congress). But, so what? RFCs are the tool that we have for > communicating such non-protocol matters as IETF process, so we might as > well use them to "impose" mandates on protocol designers. > >> - There is no explanation of why an Informational RFC have any effect >> on IETF standards-track documents. > > Even if it were a standards track RFC it still couldn't have any more > effect on future standards-track RFCs than... the IESG and IETF are > willing to enforce when reviewing future submissions. See above. No, there's a big difference here. A published BCP represents IETF consensus on an issue, and authors of later documents should expect to be consistent with that consensus, demonstrate (to the level of a new IETF consensus) why the new dociment should be differnet, or not have the new document progress. For example, if you try to progress a document that defines a new security protocol which doesn't include automatic key management, you'd better explain why that's OK or expect me to throe RFC4107 at you. In such a situation, I don't need to build an IETF consensus that automatic key management is a good idea and that you need to demonstrate why manual keying is appropriate for your protocol -- BCP107 represents such a consensus, both in the security area and, presumably, in the IETF as a whole. By contrast, an Informational RFC does not necessarily represent such a consensus, and the process for approving one is not designed to ensure that it does. This is one of the reasons we use BCP's to define IETF process - a BCP represents community consensus, while an Informational RFC does not. So yes, if this document intends to impose a mandate, then it needs to be published as a BCP with an appropriate IETF-wide last call period. -- Jeff From Nicolas.Williams@oracle.com Mon Oct 4 14:52:33 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13FA33A6E15; Mon, 4 Oct 2010 14:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 u6fKyq4vC-2T; Mon, 4 Oct 2010 14:52:30 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id C51E73A6CB6; Mon, 4 Oct 2010 14:52:27 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o94LrLef016963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Oct 2010 21:53:22 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o94LKu3f028958; Mon, 4 Oct 2010 21:53:19 GMT Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 661550251286229153; Mon, 04 Oct 2010 14:52:33 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Oct 2010 14:52:32 -0700 Date: Mon, 4 Oct 2010 16:52:28 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20101004215227.GQ9501@oracle.com> References: <4CA65AD7.80300@ieca.com> <1702_1286218784_o94IxhJi008577_20101004185831.GJ9501@oracle.com> <9E4F286124541057D85563F1@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9E4F286124541057D85563F1@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: cfrg@irtf.org, Paul Hoffman , saag@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 21:52:33 -0000 On Mon, Oct 04, 2010 at 05:44:51PM -0400, Jeffrey Hutzelman wrote: > --On Monday, October 04, 2010 01:58:33 PM -0500 Nicolas Williams > wrote: > >Even if it were a standards track RFC it still couldn't have any more > >effect on future standards-track RFCs than... the IESG and IETF are > >willing to enforce when reviewing future submissions. See above. > > No, there's a big difference here. A published BCP represents IETF > consensus on an issue, and authors of later documents should expect > to be consistent with that consensus, demonstrate (to the level of a > new IETF consensus) why the new dociment should be differnet, or not > have the new document progress. Sure. But BCP != Standards-Track. Also, I did state that "[g]uidance such as this belongs in a BCP" -- my reply to Paul wasn't so long that you could have missed that :) And still, BCPs are not self-enforcing. The IETF and the IESG need to enforce them actively. I think we're in agreement. From paul.hoffman@vpnc.org Mon Oct 4 15:10:14 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0403A6E8E; Mon, 4 Oct 2010 15:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.397 X-Spam-Level: X-Spam-Status: No, score=-101.397 tagged_above=-999 required=5 tests=[AWL=0.649, 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 P+2YYDxihSj2; Mon, 4 Oct 2010 15:10:13 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6B4DC3A6CB0; Mon, 4 Oct 2010 15:10:13 -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 o94M7I9x024413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Oct 2010 15:07:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20101004215227.GQ9501@oracle.com> References: <4CA65AD7.80300@ieca.com> <1702_1286218784_o94IxhJi008577_20101004185831.GJ9501@oracle.com> <9E4F286124541057D85563F1@minbar.fac.cs.cmu.edu> <20101004215227.GQ9501@oracle.com> Date: Mon, 4 Oct 2010 15:07:16 -0700 To: Nicolas Williams , Jeffrey Hutzelman From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 22:10:14 -0000 At 4:52 PM -0500 10/4/10, Nicolas Williams wrote: >Sure. But BCP != Standards-Track. BCP ~= Standards Track. From RFC 2026: 5. BEST CURRENT PRACTICE (BCP) RFCs The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. >And still, BCPs are not self-enforcing. The IETF and the IESG need to >enforce them actively. Indeed. >I think we're in agreement. Indeed. --Paul Hoffman, Director --VPN Consortium From pgut001@cs.auckland.ac.nz Mon Oct 4 20:40:44 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9E223A6E0C for ; Mon, 4 Oct 2010 20:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYqBVu0AK+YR for ; Mon, 4 Oct 2010 20:40:44 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id A5CBF3A6C5E for ; Mon, 4 Oct 2010 20:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1286250101; x=1317786101; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20dharkins@lounge.org|Subject:=20Re:=20[saag]=20[Cfr g]=20[Fwd:=20I-D=20ACTION:draft-turner-sha0-sha1-seccon-0 0.txt]|Cc:=20cfrg@irtf.org,=20saag@ietf.org|In-Reply-To: =20<092405dc28038119878c75f1b01f29bc.squirrel@www.trepann ing.net>|Message-Id:=20|Date:=20Tue,=2005=20Oct=202010=2016:41:1 6=20+1300; bh=NHYORsSzzYCpj+b9MyRWlo6JZGDRxsqIUere6o1NOko=; b=noUTZK2mzexj10vPmWJETnsZpAhoITqjc7oT8HnKIiiTCphloGTC8R93 bi/XeRbJ5QmqpNeoT5UOX3vIBGicFqDRuG/O8UEVsW4fE55hLd5HRsfcz CXV3/gU8dyhvxrAG9w+oCb9GqULwHXsQf3L7rR4SBXcKQ2Cl9ZvEKGXsw 0=; X-IronPort-AV: E=Sophos;i="4.57,281,1283688000"; d="scan'208";a="29741845" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Oct 2010 16:41:16 +1300 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1P2yOy-0003pb-DM; Tue, 05 Oct 2010 16:41:16 +1300 From: Peter Gutmann To: dharkins@lounge.org In-Reply-To: <092405dc28038119878c75f1b01f29bc.squirrel@www.trepanning.net> Message-Id: Date: Tue, 05 Oct 2010 16:41:16 +1300 Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 03:40:45 -0000 "Dan Harkins" writes: >That's an odd statement. There is suite B guidance for use of quite alot of >IETF protocols-- TLS, SSH, IKE/IPsec, S/MIME And how many of those have you see used outside the USG, which operates more or less in its own world anyway? Peter. From hotz@jpl.nasa.gov Mon Oct 4 23:31:30 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1241A3A6CC4; Mon, 4 Oct 2010 23:31: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 uN4NsaD2zTzW; Mon, 4 Oct 2010 23:31:28 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by core3.amsl.com (Postfix) with ESMTP id 224C03A6A03; Mon, 4 Oct 2010 23:31:27 -0700 (PDT) Received: from [192.168.2.2] (netblock-72-25-120-25.dslextreme.com [72.25.120.25]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id o956WJUv003565 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 4 Oct 2010 23:32:21 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <201010050046.o950kBPe005266@fs4113.wdf.sap.corp> Date: Mon, 4 Oct 2010 23:32:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <79D1362B-40D5-4990-BD7F-913903837907@jpl.nasa.gov> References: <201010050046.o950kBPe005266@fs4113.wdf.sap.corp> To: "mrex@sap.com" X-Mailer: Apple Mail (2.1081) X-Source-IP: netblock-72-25-120-25.dslextreme.com [72.25.120.25] X-Source-Sender: hotz@jpl.nasa.gov X-Spamclassfication-Commtouch: not spam X-SpamRefId: str=0001.0A090204.4CAAC677.006E,ss=1,fgs=0 Cc: "pkix@ietf.org" , "dnsop@ietf.org" , Michael StJohns , "saag@ietf.org" , "tls@ietf.org" Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 06:31:30 -0000 On Oct 4, 2010, at 5:46 PM, Martin Rex wrote: >> DNSSEC provides a "secure" association FROM the name TO the IP = address. >> But the DNS domain owner tends not to be the host owner so this = asserted >> association may not reflect the intent of the host owner. >> Also, DNSSEC doesn't protect from IP hijacking (re-routing). >=20 > Incorrect characterisation. DNSSEC provides only for secure = distribution > of DNS records. Whether the distributed DNS records are accurate or > trustworthy is a completely distinct issue. I think secure distribution of DNS records implies secure distribution = of name to IP associations. =20 Whether those records are depends on the practices of the = domain administrator. Is a 3rd party CA is more or less (likely to be) = trustworthy than the relevant domain administrator? ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From mouse@Sparkle.Rodents-Montreal.ORG Tue Oct 5 01:00:07 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0086E3A6BF0; Tue, 5 Oct 2010 01:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.46 X-Spam-Level: X-Spam-Status: No, score=-8.46 tagged_above=-999 required=5 tests=[AWL=1.528, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VKelxu700Ha; Tue, 5 Oct 2010 01:00:06 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 5C03A3A6A6C; Tue, 5 Oct 2010 01:00:05 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id EAA11862; Tue, 5 Oct 2010 04:00:55 -0400 (EDT) Date: Tue, 5 Oct 2010 04:00:55 -0400 (EDT) From: der Mouse Message-Id: <201010050800.EAA11862@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Tue, 5 Oct 2010 03:51:36 -0400 (EDT) To: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org In-Reply-To: <79D1362B-40D5-4990-BD7F-913903837907@jpl.nasa.gov> References: <201010050046.o950kBPe005266@fs4113.wdf.sap.corp> <79D1362B-40D5-4990-BD7F-913903837907@jpl.nasa.gov> Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 08:00:07 -0000 >>> DNSSEC provides a "secure" association FROM the name TO the IP >>> address. >> Incorrect characterisation. DNSSEC provides only for secure >> distribution of DNS records. Whether the distributed DNS records >> are accurate or trustworthy is a completely distinct issue. > I think secure distribution of DNS records implies secure > distribution of name to IP associations. Yes, it does, name-to-IP associations being one of the major things the DNS is used for. But the original statement was that DNSSEC provides "secure" association from name to IP. This is a stronger property than providing secure distribution of name-to-IP mapping information; it also implies that the creation of that information and its injection into the distribution mechanisms are "secure" (whatever that means - I note that none of these say what they are talking about being secure against; perhaps I'm just missing context). > Is a 3rd party CA is more or less (likely to be) trustworthy than the > relevant domain administrator? There are (at least moderately) common scenarios in which it's the one way around; there are other similarly common scenarios in which it's the other - at least for most types of trust; again, this doesn't give much hint of the threat model of interest. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From ondrej.sury@nic.cz Tue Oct 5 09:50:27 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C24E3A6FDD; Tue, 5 Oct 2010 09:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.917 X-Spam-Level: X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DznwKE+wEkb; Tue, 5 Oct 2010 09:48:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 6BB283A6CE1; Tue, 5 Oct 2010 09:48:30 -0700 (PDT) Received: from [10.168.66.81] (89-24-7-50.i4g.tmcz.cz [89.24.7.50]) by mail.nic.cz (Postfix) with ESMTPA id B87767343EE; Tue, 5 Oct 2010 18:49:26 +0200 (CEST) References: <1285970705.1984.136.camel@mattlaptop2.local> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <60283F04-0795-46E9-AE42-58EA099A9BF5@nic.cz> X-Mailer: iPhone Mail (8B117) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Date: Tue, 5 Oct 2010 18:49:26 +0200 To: "Kemp, David P." Cc: "dnsop@ietf.org" , "saag@ietf.org" , "pkix@ietf.org" , Phillip Hallam-Baker , "tls@ietf.org" Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 16:50:27 -0000 You are working on wrong assumptions. The DV certs are exactly as strong as y= our DNS is. You only need to attack DNS to issue a DV cert. Ondrej Sury On 5.10.2010, at 18:32, "Kemp, David P." wrote: > You are confusing attack surface with vulnerability. Without getting > into technology specifics, if A .and. B must be successfully attacked in > order to cause a problem, then having two systems can only reduce the > vulnerability even though there are more places to attack. >=20 > If the problem is availability, then the best strategy is redundancy - > use multiple sources for a single information item. If the problem is > integrity, the best strategy is diversity - use different sources for > different information items. If either source gives the wrong answer > you fail, but fail safely. (Redundancy and diversity can be combined of > course, but then combining rules such voting thresholds have to be > specified).=20 >=20 > For the DNS/PKI case, if A is an IP address for a dnsname and B is a > public key for a dnsname, then it is necessary to attack the sources of > A and B in order to successfully spoof a named server. If A and B come > from the same system (e.g., DNS) it is necessary to attack only that > system. If they come from different systems (DNS and PKI) then it is > necessary to attack both. Attacking only one may cause an availability > failure, but not an integrity failure. >=20 > Dave >=20 >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Ben Laurie >=20 >=20 > If I deploy the DNS solution, stating that DNS is authoritative, then > my attack surface now excludes all CAs. How is that an increase in > attack surface? >=20 > Contrast with today's situation, where my attack surface is increased > on a regular basis by the introduction of new CAs, without any > consultation with me at all. >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Tue Oct 5 11:40:18 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D6163A70BA; Tue, 5 Oct 2010 11:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 9TvMxoDE4Ydu; Tue, 5 Oct 2010 11:40:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 333353A6FDC; Tue, 5 Oct 2010 11:40:17 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49202) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P3CRu-000AjT-Vd; Tue, 05 Oct 2010 14:41:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20101004183043.733393A7052@core3.amsl.com> References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> <4CA9EED5.5050006@extendedsubset.com> <20101004183043.733393A7052@core3.amsl.com> Date: Tue, 5 Oct 2010 14:41:06 -0400 To: Michael StJohns From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 18:40:18 -0000 At 2:30 PM -0400 10/4/10, Michael StJohns wrote: >Hi - > >DNSSEC seems to be picking on PKIX and vice versa - maybe the right >answer is both? I don't see the proposed work as a war between X.509 certs and signed DNS records. I think that they are potentially complementary security mechanisms. >... >What if - the PKIX certificate for the host contained a "permit" for >the name signed by the DNS owner? A signature over the hash of the >public key in the certificate, and the DNS name - and maybe some >expiration info verifiable by the data in DNSSEC? We have avoided putting additional signatures in a public-key cert, so I'm not comfortable with a proposal that does so. Is there a way to reverse this, so that the cert contains a hash of a key from the DNS, and there is a (signed) DNS record that covers the cert? Steve From paul.hoffman@vpnc.org Tue Oct 5 12:02:13 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3DBF3A6FEE; Tue, 5 Oct 2010 12:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.406 X-Spam-Level: X-Spam-Status: No, score=-101.406 tagged_above=-999 required=5 tests=[AWL=0.640, 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 hrR08f0ZmEmj; Tue, 5 Oct 2010 12:02:12 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CA3483A6FD9; Tue, 5 Oct 2010 12:02:12 -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 o95J37It091667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Oct 2010 12:03:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 5 Oct 2010 12:03:06 -0700 To: Phillip Hallam-Baker From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 19:02:13 -0000 As much as I hate to spam multiple lists, I need to correct a technical error. And, really, this discussion should be happening on the keyassure mailing list. At 12:56 PM -0400 10/5/10, Phillip Hallam-Baker wrote: >But the design approach taken in the Hoffman et. al. proposal is that publication of a DNSSEC assurance for a cert disables verification on the PKIX chain unless the 'preferences' flag is set. That statement was untrue in draft-hoffman-keys-linkage-from-dns-02, and the flag was removed in -03. --Paul Hoffman, Director --VPN Consortium From Nicolas.Williams@oracle.com Tue Oct 5 12:03:02 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5941C3A70DA; Tue, 5 Oct 2010 12:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 jix4IqZDdigz; Tue, 5 Oct 2010 12:03:01 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5EAE23A6FED; Tue, 5 Oct 2010 12:03:01 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o95J3tu4000412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Oct 2010 19:03:57 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o95CmLZC002871; Tue, 5 Oct 2010 19:03:55 GMT Received: from abhmt005.oracle.com by acsmt354.oracle.com with ESMTP id 664713501286305377; Tue, 05 Oct 2010 12:02:57 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Oct 2010 12:02:57 -0700 Date: Tue, 5 Oct 2010 14:02:52 -0500 From: Nicolas Williams To: Phillip Hallam-Baker Message-ID: <20101005190251.GY9501@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 19:03:02 -0000 On Fri, Oct 01, 2010 at 11:29:35AM -0400, Phillip Hallam-Baker wrote: > What I object to is the approach being taken which is to use DNSSEC to > replace PKIX certificate validation entirely. > > Now the proponents are trying to downplay this by saying that 'all' they are > doing is to tell people to 'ignore' PKIX validation. But that approach > really offends my sense of layering. I think the layering argument is the strongest argument here. To be sure, the KEYASSURE approach offends my sense of layering too, but not in the same way: IMO this is a change to how certificate validation is done, therefore an update to RFC5280, ISTM, is required. What I'd like to see is for the DNSSEC approach to certificate validation be considered as a change to TLS and/or PKIX. That is: - RFC5280 should be updated to describe DNSSEC-based validation of certificates. There are a number of security considerations here that must be considered in the context of PKIX. For example: can a DNSSEC- validated certificate be a CA certificate, and if so, what might its scope be? Are there implied naming constraints? Or: when is it OK to try one (traditional PKIX valdiation) or the other (DNSSEC), and when is it OK to fallback on the other? (Perhaps this is what you meant by giving the attacker two infrastructures to attack. If the validation policy of the rp can be forced to fallback on a less preferred mechanism via a DoS attack, then the attacker has something to work with.) I've _not_ reviewed the KEYASSURE documents, so I'm not sure if these security considerations are being addressed/documented. - TLS implementations should offer applications whatever choices the update to RFC5280 requires, if any. Choices such as: validation policy choices (trad-PKIX-only, DNSSEC-only, trad-PKIX-and-DNSSEC, DNSSEC-fallback-on-trad-PKIX-only-if-NXDOMAIN-is-secured, DNSSEC- fallback-on-trad-PKIX). TLS doesn't have abstract interfaces, but some text regarding this in an update to TLS 1.2 seems appropriate to me. Alternatively, such text could belong in the RFC5280 update, but even then, I think TLS implementors specifically need to be made aware of this new certificate validation option and its security considerations. The main security consideration here is, I think, about when to try one, the other, or both of traditional PKIX or DNSSEC certificate validation. Nico -- From sm@resistor.net Tue Oct 5 13:38:02 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F033A6FB8 for ; Tue, 5 Oct 2010 13:38:02 -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 2EJNmnYCrwOU for ; Tue, 5 Oct 2010 13:37:55 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 541503A6C4E for ; Tue, 5 Oct 2010 13:37:55 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o95KcQPT018059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Oct 2010 13:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1286311132; x=1286397532; bh=QzV5B2gtc+4PgidQ0KjmxG6TfGVc6gCGoQy0XpS8bBY=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=dLq63VQn3UopQfQy8VF9QrR7fFVFvPb4nPRqzDSVR60O168HgWTUS9xM9EYJ3Kur2 Gpl46Vkb5dYoKT3xzVOKZRohEeWG93SJuBWvNZdIHuY+Sv7UtSGM5u9Vrl9y7k4f+V qe11BJcw9lZz5pcxQgpc24mFAyT4pf74Vy+6v9Zc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1286311132; x=1286397532; bh=QzV5B2gtc+4PgidQ0KjmxG6TfGVc6gCGoQy0XpS8bBY=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=q0eOkk0D7hQxYr0mY0pY6aTzj79cY0oaD5d4/J+zfUtDjnGMEUIGpU/f7p0brmtQQ uMR+Wy7Hn0lmypVZE+hHqlx+AtvdTRJbcaU6D3Hq+E4oPiePIE5FN1jGgbbqf6LiHv gvcJBehQ9vkX7CxmDR0Lcn0as0xEDKItq3FCa35g= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=D3Y2gz+hPLUeN+CxUtJDSkzr5RUlap7CDTP1SE1gQ6XxH6qnZ6P6sc9Qt9MD6BRFW jJI59uc2gxcRvysaCsLQhs/rc83hjyHjactzjCHTkq47zS5Yr/rbGb6AIkCumc1hE4c CHr4J8B0Qsl4wl8hyDzpo0h7kM0HuweIWp1ojc0= Message-Id: <6.2.5.6.2.20101005130846.09be03e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Oct 2010 13:29:31 -0700 To: saag@ietf.org From: SM In-Reply-To: <9E4F286124541057D85563F1@minbar.fac.cs.cmu.edu> References: <4CA65AD7.80300@ieca.com> <1702_1286218784_o94IxhJi008577_20101004185831.GJ9501@oracle.com> <9E4F286124541057D85563F1@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 20:38:02 -0000 At 14:44 04-10-10, Jeffrey Hutzelman wrote: >By contrast, an Informational RFC does not necessarily represent >such a consensus, and the process for approving one is not designed >to ensure that it does. This is one of the reasons we use BCP's to >define IETF process - a BCP represents community consensus, while an >Informational RFC does not. Please see the "Status of This Memo" in RFC 5968, RFC 5982 RFC 5997, RFC 6007 and RFC 6018. According to the text, the Informational RFC represents the consensus of the IETF community. Regards, -sm From hallam@gmail.com Fri Oct 1 08:28:50 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2703A6AED; Fri, 1 Oct 2010 08:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Yvr2-up3+c3A; Fri, 1 Oct 2010 08:28:48 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A73453A6BE6; Fri, 1 Oct 2010 08:28:47 -0700 (PDT) Received: by wyi11 with SMTP id 11so3573414wyi.31 for ; Fri, 01 Oct 2010 08:29:35 -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:cc:content-type; bh=wloNndc5fE2e4RtCUQCjnoCy+YP7T63wIiKSnSYLhTo=; b=NExISL7+64tvOClnix++OMZN8zgy0kiSZCIl7fbX0idLone+zhFZcIYlyeUFG79kRO Za+7qZVqkvLbvsedkOGdB5Py3BkcHcM91rrIxmH2y0ksbj8+xKsiwqwYLpG9Fh8Odq3d mbAFfjeQCUVRxLoPP0h0U3j3OZxLcJhgR8xXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=rPoA9R0hYzobXvTJ5rmmi3DyjIBdARhOEpFDmojwsw4XYWxFRaFp3vc6DaqvFigS9L WIOvMODqDLs9ivlRKosEQ+BPnhfDTrzIyM5Kgy0NQcBmzV0jQ9XiUNz/o+pE2uFsOfll gondrahse1RprJh/iExG6ZTe6fkQRUFYEUP5k= MIME-Version: 1.0 Received: by 10.216.11.201 with SMTP id 51mr2254523wex.72.1285946975359; Fri, 01 Oct 2010 08:29:35 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Fri, 1 Oct 2010 08:29:35 -0700 (PDT) Date: Fri, 1 Oct 2010 11:29:35 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=0016364c7bd1aabebf04918fdc0a X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, tls@ietf.org, saag@ietf.org Subject: [saag] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 15:28:50 -0000 --0016364c7bd1aabebf04918fdc0a Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable For the past month I have been participating in the KEYASSURE discussions. One aspect of those discussions that was not made clear in the original notice sent out is that the group is not only considering key assurance, th= e proposals made are also intended to have security policy semantics. This was not apparent to me from reading the list announcement, the initial proposed charter or the Internet drafts. I have asked the organizers of the group to clarify the matter in the wider IETF community but they have not done so. In particular I am very concerned about the particular approach being taken to security policy. What the proposers are attempting to do is to create a mechanism that allows a site that only uses one particular high assurance C= A to 'protect' themselves against SSL certificates being issued by low assurance CAs. As such, this is an objective I approve of and is one that I would like to see supported in a generalized security policy. It should be possible for a site to make security policy statements of the form 'all valid PKIX certs for example.com have cert X in the validation path'. What I object to is the approach being taken which is to use DNSSEC to replace PKIX certificate validation entirely. Now the proponents are trying to downplay this by saying that 'all' they ar= e doing is to tell people to 'ignore' PKIX validation. But that approach really offends my sense of layering. Worse still, the proponents refuse to allow any method of shutting this system off. So if I have a site where I want to use DNSSEC validated certificates on the mail server, deployment is going to impact my Web server. Specifically the proposal amounts to using the DNS CERT record to publish a fingerprint of all the certificates permitted for use with TLS at a specifi= c domain: example.com CERT TLSFP 0 0 example.com CERT TLSFP 0 0 It is proposed to replace current TLS certificate processing semantics with the following: 1) Query for CERT record at example.com 2) If no CERT record with TLSFP certificate type exists then perform normal PKIX validation and return that result 3) Otherwise attempt to match the TLS end entity certificate with one of th= e fingerprints specified in the published TLSFP RRs 4) If a match is found return VALID, otherwise return INVALID Note here that if there is a TLSFP RR that it takes precedence over PKIX processing rules. There should of course be DNSSEC validation performed in that process as well, but the authors have not explained how that is meant to work in the context of their proposal so I left it out. The defenses made for this approach are of the form 'you have to wear big pants to play this game'. In other words if people are going to administer these systems and not be burned they are going to have to understand what they are doing. I do not consider this a responsible approach to protocol design. What I would prefer is to have systems that do not need to be administered by people at all. That is not possible when the approach has hidden side effects that cannot be anticipated by scripts. I am very much committed to the idea of doing security policy. But this is not an approach I can support. Any policy mechanism has to be orthogonal to the key validation strategy in my view. I should be able to use any DNS security policy mechanism that the IETF endorses with PKIX certificate processing semantics. I have proposed an alternative approach in http://tools.ietf.org/html/draft-hallambaker-esrv-00 This does not currently contain a mechanism to express trust restrictions but is designed to be extensible to support such. When I proposed ESRV I wa= s unaware that the KEYASSURE proposal was intended to have a security policy aspect at all. It is still not made explicit in their draft. Using the revised version of ESRV I am currently writing, a security policy of the form 'always use TLS with any protocol at example.com' would have th= e form: example.com ESRV "tls=3Drequired" A security policy that was specific to http would be expressed as: example.com ESRV "prefix=3D_http._tcp" _http._tcp.example.com ESRV "tls=3Drequired" or example.com ESRV "prefix=3D*" _http._tcp.example.com ESRV "tls=3Drequired" The reason for this change from the -00 version is that this approach supports CNAMEs. The reason that I started with the requirement to use SSL is that security policy relating to trust criteria is meaningless until you have a statement that use of SSL is required. I have no objection to doing security policy. But I do have a real objectio= n to an approach that negates PKIX semantics as the TLSFP approach does. -------- Original Message -------- > Subject: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC > Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT) > From: IETF Secretariat > To: IETF Announcement list > CC: keyassure@ietf.org, ondrej.sury@nic.cz, warren@kumari.net > > 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 t= o > eliminate the need for using a certificate in a protocol, to eliminate th= e > need for sending certificates in the protocol if they are optional, and/o= r > 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 wit= h > the domain name that was used in the DNS query. > > For additional information, please contact the list administrators. > > > -- > 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 > ------------------------------------------- > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --=20 Website: http://hallambaker.com/ --0016364c7bd1aabebf04918fdc0a Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable
For the past month I have been participatin= g in the KEYASSURE discussions.

One aspect of thos= e discussions that was not made clear in the original notice sent out is th= at the group is not only considering key assurance, the proposals made are = also intended to have security policy semantics.

This was not apparent to me from reading the list annou= ncement, the initial proposed charter or the Internet drafts. I have asked = the organizers of the group to clarify the matter in the wider IETF communi= ty but they have not done so.


In particular I am very concerned about = the particular approach being taken to security policy. What the proposers = are attempting to do is to create a mechanism that allows a site that only = uses one particular high assurance CA to 'protect' themselves again= st SSL certificates being issued by low assurance CAs.

As such, this is an objective I approve of and is one t= hat I would like to see supported in a generalized security policy. It shou= ld be possible for a site to make security policy statements of the form &#= 39;all valid PKIX certs for example.com = have cert X in the validation path'.


What I object to is the approach being t= aken which is to use DNSSEC to replace PKIX certificate validation entirely= .

Now the proponents are trying to downplay this b= y saying that 'all' they are doing is to tell people to 'ignore= ' PKIX validation. But that approach really offends my sense of layerin= g.=A0

Worse still, the proponents refuse to allow any method = of shutting this system off. So if I have a site where I want to use DNSSEC= validated certificates on the mail server, deployment is going to impact m= y Web server.


Specifically the proposal amounts to usi= ng the DNS CERT record to publish a fingerprint of all the certificates per= mitted for use with TLS at a specific domain:

example.com CERT TLSFP 0 0 <digest ce= rt 1>
example.com CERT TLSF= P 0 0 <digest cert 2>

It is proposed to repl= ace current TLS certificate processing semantics with the following:

1) Query for CERT record at example.com
2) If no CERT record with TLSFP certificate t= ype exists then perform normal PKIX validation and return that result
3) Otherwise attempt to match the TLS end entity certificate with one = of the fingerprints specified in the published TLSFP RRs
4) If a = match is found return VALID, otherwise return INVALID

Note here that if there is a TLSFP RR that it takes precedence over PK= IX processing rules.

There should of course be DNS= SEC validation performed in that process as well, but the authors have not = explained how that is meant to work in the context of their proposal so I l= eft it out.=A0


The defenses made for this approach are = of the form 'you have to wear big pants to play this game'. In othe= r words if people are going to administer these systems and not be burned t= hey are going to have to understand what they are doing. I do not consider = this a responsible approach to protocol design.

What I would prefer is to have systems that do not need= to be administered by people at all. That is not possible when the approac= h has hidden side effects that cannot be anticipated by scripts.


I am very much committed to the idea of doing= security policy. But this is not an approach I can support. Any policy mec= hanism has to be orthogonal to the key validation strategy in my view. I sh= ould be able to use any DNS security policy mechanism that the IETF endorse= s with PKIX certificate processing semantics.=A0

I have proposed an alternative approach in=A0

This does not currently contain a mechanism to express trust res= trictions but is designed to be extensible to support such. When I proposed= ESRV I was unaware that the KEYASSURE proposal was intended to have a secu= rity policy aspect at all. It is still not made explicit in their draft.


Using the revised version of ESRV I am c= urrently writing, a security policy of the form 'always use TLS with an= y protocol at example.com' would hav= e the form:

example.com ESRV &qu= ot;tls=3Drequired"

A security policy that was= specific to http would be expressed as:

example.com ESRV "prefix=3D_http._tcp"= ;
_http._tcp.example.com ESRV &qu= ot;tls=3Drequired"

or=A0

=
example.com ESRV "prefix= =3D*"
_http._tcp.example.com ESRV &qu= ot;tls=3Drequired"

The reason for this = change from the -00 version is that this approach supports CNAMEs.=A0
=


The reason that I started with the requiremen= t to use SSL is that security policy relating to trust criteria is meaningl= ess until you have a statement that use of SSL is required.


I have no objection to doing security policy. But= I do have a real objection to an approach that negates PKIX semantics as t= he TLSFP approach does.


-------- Original Message --------
Subject: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT)
From: IETF Secretariat <ietf-secretariat@ietf.org>
To: IETF Announcement list <ietf-announce@ietf.org>
CC: keyassure@ietf.= org, ondrej.sur= y@nic.cz, warren= @kumari.net

A new IETF non-working group email list has been created.

List address: keyas= sure@ietf.org
Archive:
http://www.ietf.org/mail-archive/web/keyassure/curr= ent/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 t= hat a relying party can get additional information about a domain name to e= liminate the need for using a certificate in a protocol, to eliminate the n= eed for sending certificates in the protocol if they are optional, and/or t= o assure that the certificate given in a protocol is associated with the do= main name used by the application. In all three cases, the application asso= ciates 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.


--
=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.su= ry@nic.cz =A0 =A0http://ni= c.cz/
=A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112
=A0-------------------------------------------
_______________________________________________
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag



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

--0016364c7bd1aabebf04918fdc0a-- From hallam@gmail.com Fri Oct 1 09:14:15 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96AC53A6BEB; Fri, 1 Oct 2010 09:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.338, 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 7tVkwBv1qNhb; Fri, 1 Oct 2010 09:14:13 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id A2C483A6ABB; Fri, 1 Oct 2010 09:14:12 -0700 (PDT) Received: by ewy26 with SMTP id 26so1709648ewy.31 for ; Fri, 01 Oct 2010 09:15:00 -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=FqE/B5aGA/1LaXPUUcHMvnug5zrpYbDddp7UuNuCXHg=; b=ICZUHN62KPh0ADie7F1A26tX1rvZTbV5k7XIHSieapFYRJXPGmmdFHwbWfLgHYz/x3 cizp1entErFDC/0GDSaeY4mpDNSQp8+ysudg812GirpFzUYAZjkK74bYEA33/OpxYlSF CNLjziPSUNpIGwzlPu7KTLyKRmnKu6fQblyHg= 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=GtF2eMCuvWEqfU8Fda3/G7SYthUI1l+JV4zRf7t6SqxLT3vcCiQk0StJ4EYm1VFPY2 zJXRMG++ehdGIXrxDb1BplI0cInvB4CsSu+lwfw9lerhUFfV5s+uMJ2FWBPZ7aM3Q8EU YcYTnKWXT50piOm11kinrWTQ7NWiSXHIJLsVM= MIME-Version: 1.0 Received: by 10.216.47.80 with SMTP id s58mr4717009web.15.1285949700189; Fri, 01 Oct 2010 09:15:00 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Fri, 1 Oct 2010 09:15:00 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Oct 2010 12:15:00 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=001485f28010142d3d0491907f83 X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 16:14:16 -0000 --001485f28010142d3d0491907f83 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 1, 2010 at 12:02 PM, Ben Laurie wrote: > On 1 October 2010 08:29, Phillip Hallam-Baker wrote: > > The reason that I started with the requirement to use SSL is that > security > > policy relating to trust criteria is meaningless until you have a > statement > > that use of SSL is required. > > I can't agree with this. If a user types an https URL, say, then > there's every reason security policy should apply despite the lack of > a statement that SSL is required. I regard typing https as being a policy statement. I don't think anyone could use the TLSFP scheme as a substitute for DV validation for about a decade. As of today 0% of the deployed browsers support TLSFP so if someone types https and the cert is not DV validated they are going to see the self-signed cert warning box. What I would see as being much more practical is a scheme that works automatically when the user types in http. If the browser does not support the DNS mechanism then the user goes to the site unencrypted as they do today. If the browser and site both support the DNS mechanism, the communication is encrypted and the user need not know anything about it. I would like to get rid of the padlock entirely and eventually go to a user experience when the user is only warned when going to one of the few remaining sites that does NOT offer free transparent security. > I have no objection to doing security policy. But I do have a real > objection > > to an approach that negates PKIX semantics as the TLSFP approach does. > > Then I'd like to see your proposal for _optionally_ allowing PKIX to > be overridden. > _http._tcp.example.com ESRV "TLS=required CERTFP=required" This is still a potential shoot-in-foot situation for humans. But I can write a script that can extract the necessary information to do the job right. -- Website: http://hallambaker.com/ --001485f28010142d3d0491907f83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Oct 1, 2= 010 at 12:02 PM, Ben Laurie <benl@google.com> wrote:
On 1 October 2010 08:29, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> The reason that I started with the requirement to use SSL is that secu= rity
> policy relating to trust criteria is meaningless until you have a stat= ement
> that use of SSL is required.

I can't agree with this. If a user types an https URL, say, then<= br> there's every reason security policy should apply despite the lack of a statement that SSL is required.

I regard = typing https as being a policy statement.

I don= 9;t think anyone could use the TLSFP scheme as a substitute for DV validati= on for about a decade. As of today 0% of the deployed browsers support TLSF= P so if someone types https and the cert is not DV validated they are going= to see the self-signed cert warning box.


What I would see as being much more prac= tical is a scheme that works automatically when the user types in http.

If the browser does not support the DNS mechanism the= n the user goes to the site unencrypted as they do today.

If the browser and site both support the DNS mechanism,= the communication is encrypted and the user need not know anything about i= t.


I would like to get rid of the p= adlock entirely and eventually go to a user experience when the user is onl= y warned when going to one of the few remaining sites that does NOT offer f= ree transparent security.

> I have no objection to doing security policy. But I do have a real obj= ection
> to an approach that negates PKIX semantics as the TLSFP approach does.=

Then I'd like to see your proposal for _optionally_ allowing PKIX= to
be overridden.

_http._tcp.exampl= e.com ESRV "TLS=3Drequired CERTFP=3Drequired"

This is still a potential shoot-in-foot situation for huma= ns. But I can write a script that can extract the necessary information to = do the job right.
--001485f28010142d3d0491907f83-- From matt@mattmccutchen.net Fri Oct 1 15:04:19 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7263A6B53; Fri, 1 Oct 2010 15:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 fvc0pvRC7bdu; Fri, 1 Oct 2010 15:04:18 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 5492A3A6BB0; Fri, 1 Oct 2010 15:04:18 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 5D96834806B; Fri, 1 Oct 2010 15:05:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=OpP0D9TaeHptlNmYa4dRkFHnDw6hVQNcmPyajj9mEFv 7kzORmTmvlcthbZvbIz3iDyjs8fU1l+p0PHYnmIqUY2mBnV8WINqN6WsiPOjWqMc pn8UY85owiHMtmy4U7whJtTfOwe2LOgj8rYSeltzP3LlKw0/rIIQWd4USmrMa1QY = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=u2HyGA1rvJ9KQf5QThA96tu+6xo=; b=HPeUWyXVNt qyPv6HB8eoVhg2W+l5Kg8oxM/pn7WCAeWotpjMSZqNgc8XLBtFjiU1WA7lJf8i/t w2ns9mBlwFma7xLh0gjdsc2/WEitijDcMr2hN+8NSpv1eZ+1/L2s4+JlIvrrzqx4 hMfnZxPJUTGk+hxhtqhPqqITcb28MyX0k= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id AFE4E348060; Fri, 1 Oct 2010 15:05:06 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Fri, 01 Oct 2010 18:05:05 -0400 Message-ID: <1285970705.1984.136.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 22:04:19 -0000 On Fri, 2010-10-01 at 11:29 -0400, Phillip Hallam-Baker wrote: > In particular I am very concerned about the particular approach being > taken to security policy. What the proposers are attempting to do is > to create a mechanism that allows a site that only uses one particular > high assurance CA to 'protect' themselves against SSL certificates > being issued by low assurance CAs. > > As such, this is an objective I approve of and is one that I would > like to see supported in a generalized security policy. It should be > possible for a site to make security policy statements of the form > 'all valid PKIX certs for example.com have cert X in the validation > path'. > > What I object to is the approach being taken which is to use DNSSEC to > replace PKIX certificate validation entirely. Realize that I, and I would guess many other site admins, want precisely that. PKIX is complicated, whereas once I have a DNSSEC signed zone, placing my TLS server's certificate in the zone and knowing that clients will accept that certificate and no other could hardly be simpler. And why shouldn't I be allowed to do it? I have complete authority over my zone (even for the most part in the present public CA system). Nobody gave PKIX a monopoly on the determination of certificate acceptability. We could support a more general scheme in which positive assurance is separate from restrictions, but don't be surprised when a significant fraction of sites use it to effectively "replace PKIX certificate validation". > Worse still, the proponents refuse to allow any method of shutting > this system off. So if I have a site where I want to use DNSSEC > validated certificates on the mail server, deployment is going to > impact my Web server. Yes, there should be a way to make the exclusivity optional, but there may be better ways to solve the problem you cited, such as placing the DNSSEC certificate at the SRVName for the mail server. -- Matt From hallam@gmail.com Fri Oct 1 16:14:47 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F08F3A6D27; Fri, 1 Oct 2010 16:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.187, 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 eFOH7b7KAmeG; Fri, 1 Oct 2010 16:14:44 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 23FB23A6CC7; Fri, 1 Oct 2010 16:14:42 -0700 (PDT) Received: by wyi11 with SMTP id 11so4042702wyi.31 for ; Fri, 01 Oct 2010 16:15:31 -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=QJRoIXb7vQRUF9+U/M6eR+UKuADMDQ2lmughJq3aQWA=; b=sUd3PPd5F03ffbhNGoOPkUToJnwxhOmHBBmEBN5mvaFPBH6eecNwunbMa57Bz+saLV Ol5UGgDblUgDB7PPI8+nSsF1VrEbOPoFk7vNF3edFYe/sDfZLxTfcrMBu30D09dpwVyV 8R2YQyU+GNirgkmG5kfzVopaDkSiiRC2mjPdg= 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=bPtv+stuKmaF0U++ECUNLNI7hw2rIGxgksddL5V0wwulDelmtD0KzQgrg5QbSKJh18 XoOmt+uyg4NYUkNrh0y9UIL8nNFFpzvAT0JUjiXLkVr6ZmPFxQhqIyy30yJOfp+VgkZV 0YusViF9x1q2bvVfLgIb0Hz3+TQsqpBQcnUVE= MIME-Version: 1.0 Received: by 10.216.169.80 with SMTP id m58mr5059658wel.79.1285974931803; Fri, 01 Oct 2010 16:15:31 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Fri, 1 Oct 2010 16:15:31 -0700 (PDT) In-Reply-To: <1285970705.1984.136.camel@mattlaptop2.local> References: <1285970705.1984.136.camel@mattlaptop2.local> Date: Fri, 1 Oct 2010 19:15:31 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=0016363ba7a0000dde0491965f12 X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 23:14:47 -0000 --0016363ba7a0000dde0491965f12 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 1, 2010 at 6:05 PM, Matt McCutchen wrote: > On Fri, 2010-10-01 at 11:29 -0400, Phillip Hallam-Baker wrote: > > In particular I am very concerned about the particular approach being > > taken to security policy. What the proposers are attempting to do is > > to create a mechanism that allows a site that only uses one particular > > high assurance CA to 'protect' themselves against SSL certificates > > being issued by low assurance CAs. > > > > As such, this is an objective I approve of and is one that I would > > like to see supported in a generalized security policy. It should be > > possible for a site to make security policy statements of the form > > 'all valid PKIX certs for example.com have cert X in the validation > > path'. > > > > What I object to is the approach being taken which is to use DNSSEC to > > replace PKIX certificate validation entirely. > > Realize that I, and I would guess many other site admins, want precisely > that. PKIX is complicated, whereas once I have a DNSSEC signed zone, > placing my TLS server's certificate in the zone and knowing that clients > will accept that certificate and no other could hardly be simpler. And > why shouldn't I be allowed to do it? I have complete authority over my > zone (even for the most part in the present public CA system). Nobody > gave PKIX a monopoly on the determination of certificate acceptability. > > We could support a more general scheme in which positive assurance is > separate from restrictions, but don't be surprised when a significant > fraction of sites use it to effectively "replace PKIX certificate > validation". > > The problem with that approach is that the attacker now has two infrastructures that they can attack rather than just one. You are increasing your attack surface, not reducing and simplifying it as you might imagine. > Worse still, the proponents refuse to allow any method of shutting > > this system off. So if I have a site where I want to use DNSSEC > > validated certificates on the mail server, deployment is going to > > impact my Web server. > > Yes, there should be a way to make the exclusivity optional, but there > may be better ways to solve the problem you cited, such as placing the > DNSSEC certificate at the SRVName for the mail server. > Regardless, I believe that the PKIX and TLS groups should be aware that this is the change that has been implemented in code and is being proposed before the WG is chartered. There are much better ways to express the trust restriction semantics. I do not see why the ability to express statements concerning your trust roots needs to require deployment of a completely different mechanism and trust path for the end entity keys. For example, the ESRV mechanism is extensible. So it is possible for a site that has their own PKI and root of trust to specify that there has to be a trust path that includes that root of trust. Or you could publish a fingerprint of a cross cert that has to be involved or you could even state that there must be a cert record with the right fingerprint. -- Website: http://hallambaker.com/ --0016363ba7a0000dde0491965f12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 1, 2010 at 6:05 PM, Matt McC= utchen <matt= @mattmccutchen.net> wrote:
On Fri, 2010-10-01 at 11:29 -0400, Phillip Hallam-Baker w= rote:
> In particular I am very concerned about the particular approach being<= br> > taken to security policy. What the proposers are attempting to do is > to create a mechanism that allows a site that only uses one particular=
> high assurance CA to 'protect' themselves against SSL certific= ates
> being issued by low assurance CAs.
>
> As such, this is an objective I approve of and is one that I would
> like to see supported in a generalized security policy. It should be > possible for a site to make security policy statements of the form
> 'all valid PKIX certs for example.com have cert X in the validation
> path'.
>
> What I object to is the approach being taken which is to use DNSSEC to=
> replace PKIX certificate validation entirely.

Realize that I, and I would guess many other site admins, want precis= ely
that. =A0PKIX is complicated, whereas once I have a DNSSEC signed zone,
placing my TLS server's certificate in the zone and knowing that client= s
will accept that certificate and no other could hardly be simpler. =A0And why shouldn't I be allowed to do it? =A0I have complete authority over = my
zone (even for the most part in the present public CA system). =A0Nobody gave PKIX a monopoly on the determination of certificate acceptability.

We could support a more general scheme in which positive assurance is
separate from restrictions, but don't be surprised when a significant fraction of sites use it to effectively "replace PKIX certificate
validation".


The problem wi= th that approach is that the attacker now has two infrastructures that they= can attack rather than just one.

You are increasi= ng your attack surface, not reducing and simplifying it as you might imagin= e.
=A0

> Worse still, the proponents refuse to allow any method of shutting
> this system off. So if I have a site where I want to use DNSSEC
> validated certificates on the mail server, deployment is going to
> impact my Web server.

Yes, there should be a way to make the exclusivity optional, but ther= e
may be better ways to solve the problem you cited, such as placing the
DNSSEC certificate at the SRVName for the mail server.


Regardless, I believe that the PKIX and TLS gr= oups should be aware that this is the change that has been implemented in c= ode and is being proposed before the WG is chartered.

There are much better ways to express the trust restric= tion semantics. I do not see why the ability to express statements concerni= ng your trust roots needs to require deployment of a completely different m= echanism and trust path for the end entity keys.


For example, the ESRV mechanism is exten= sible. So it is possible for a site that has their own PKI and root of trus= t to specify that there has to be a trust path that includes that root of t= rust. Or you could publish a fingerprint of a cross cert that has to be inv= olved or you could even state that there must be a cert record with the rig= ht fingerprint.=A0

--0016363ba7a0000dde0491965f12-- From marsh@extendedsubset.com Sat Oct 2 18:48:30 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C127B3A6C5E; Sat, 2 Oct 2010 18:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.540, 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 xlPrUaJ5PNOE; Sat, 2 Oct 2010 18:48:29 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id C92A03A6C43; Sat, 2 Oct 2010 18:48:29 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1P2DhY-0004yT-Um; Sun, 03 Oct 2010 01:49:21 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DCEA86019; Sun, 3 Oct 2010 01:49:19 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19QAxKUojgP+48vkGKoVKHPuEi7YSTaDAo= Message-ID: <4CA7E120.6080701@extendedsubset.com> Date: Sat, 02 Oct 2010 20:49:20 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: Ben Laurie References: <1285970705.1984.136.camel@mattlaptop2.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, Phillip Hallam-Baker , saag@ietf.org, tls@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 01:48:30 -0000 On 10/02/2010 03:16 PM, Ben Laurie wrote: > On 1 October 2010 16:15, Phillip Hallam-Baker wrote: >> >> The problem with that approach is that the attacker now has two >> infrastructures that they can attack rather than just one. > > If I deploy the DNS solution, stating that DNS is authoritative, then > my attack surface now excludes all CAs. How is that an increase in > attack surface? > > Contrast with today's situation, where my attack surface is increased > on a regular basis by the introduction of new CAs, without any > consultation with me at all. The thing we have to to keep in mind here is that this "attack surface" is largely determined on the client of the equation. In other words, if you attempt to set policy through DNS, it only applies to clients who choose to respect it. And clients do have that annoying habit of not consulting the server admins (or the users for that matter) before changing their trust. We can blame Netscape, they intentionally set it up this way (and are no longer around to defend themselves). How much consistency is there in the current crop of PKI rules? What if DNSSEC info conflicts with other info? Vendors of client software sometimes give themselves a root cert in the client, or at least have a close relationship with some of their CAs. There's a lot of money at stake, how eager will they be to allow sites to opt-out of that trust? Some of them also sell TLS MitM interception products. The possibility that the bulk of clients will respect DNSSEC records which cut their CAs out of the trust equation any time soon seems a bit remote. We might as well be discussing the deprecation of SSLv3. It could happen eventually, but probably not in the near term. In the meantime, we'd end up with the DNS root effectively having the power of yet another CA. Except that it's not, because the various arms of ICANN and VeriSign/Symantec are probably already trusted many times over. I've seen it said that during the pre-deployment phase, the designers and promoters of DNSSEC denied they were making a replacement PKI. But the discussion now is to what extent it is inevitable. Regardless, if this is PKI 2.0 getting ready to usurp the throne, we should at least ensure that its a legitimately designed trust model this time rather than stumbling into whatever serves to enable some set of business agreements. - Marsh From hallam@gmail.com Sat Oct 2 20:29:38 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB4A3A6BDF; Sat, 2 Oct 2010 20:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, 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 1oDbC22pZ+Bn; Sat, 2 Oct 2010 20:29:37 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 748383A6A76; Sat, 2 Oct 2010 20:29:36 -0700 (PDT) Received: by wyi11 with SMTP id 11so4751547wyi.31 for ; Sat, 02 Oct 2010 20:30: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; bh=btDpdCAjR4uhSZAuFt8q+P9kcHUv+6yQttznWNOEe64=; b=Tdw32dAOahL39dgkTTWkts6hybFmtvNGLskLuqHPpVNl1tT4fYz4J4tPMMIa59esO+ sQ6mlkePvaw3wyNtB0PMUGi8TkFuOXPu5RNI/GwmYU7lsIcy4mub2pJDu+dZ+ffIUgWh WUjv8tJBM/9J4z/nvkG62C9fsyAMFTngekGeU= 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=mup5bO1KSYCXQIueGoUoYpGSWM+0nu/qp2wmE7WgHaypgqjbRvsfDtnFFCfVPU/VQ6 Q7kFiIjgJp14eJnM3GthA7pXX6eZX0alpz0cuK1bRhMAdmApe0zqSUAI9nn68QG3HbX9 05VJFfcIQv1t6T8BnHsjFQ5S8sEK2LWFQUL3I= MIME-Version: 1.0 Received: by 10.216.62.10 with SMTP id x10mr2604010wec.57.1286076627371; Sat, 02 Oct 2010 20:30:27 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Sat, 2 Oct 2010 20:30:27 -0700 (PDT) In-Reply-To: <4CA7E120.6080701@extendedsubset.com> References: <1285970705.1984.136.camel@mattlaptop2.local> <4CA7E120.6080701@extendedsubset.com> Date: Sat, 2 Oct 2010 23:30:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Marsh Ray Content-Type: multipart/alternative; boundary=000e0cdf8c9087491b0491ae0c6c X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 03:29:38 -0000 --000e0cdf8c9087491b0491ae0c6c Content-Type: text/plain; charset=ISO-8859-1 The attack surface is the number of paths that are open to an attacker. In the current model there is only one trust path, the PKIX path. In the new model, the attacker has a choice of trust paths, the PKIX path and the DNSSEC path and they can attack either of them. The problem with the DNSSEC path is that it is vulnerable to attacks against the information input to the DNS system. The weakest link there is the safeguards on registration of the DNS names. I think that whenever a proposal of this type is brought that we should be told all the considerations and all the events that are motivating the design. On Sat, Oct 2, 2010 at 9:49 PM, Marsh Ray wrote: > On 10/02/2010 03:16 PM, Ben Laurie wrote: > >> On 1 October 2010 16:15, Phillip Hallam-Baker wrote: >> >>> >>> The problem with that approach is that the attacker now has two >>> infrastructures that they can attack rather than just one. >>> >> >> If I deploy the DNS solution, stating that DNS is authoritative, then >> my attack surface now excludes all CAs. How is that an increase in >> attack surface? >> >> Contrast with today's situation, where my attack surface is increased >> on a regular basis by the introduction of new CAs, without any >> consultation with me at all. >> > > The thing we have to to keep in mind here is that this "attack surface" is > largely determined on the client of the equation. In other words, if you > attempt to set policy through DNS, it only applies to clients who choose to > respect it. And clients do have that annoying habit of not consulting the > server admins (or the users for that matter) before changing their trust. We > can blame Netscape, they intentionally set it up this way (and are no longer > around to defend themselves). > > How much consistency is there in the current crop of PKI rules? What if > DNSSEC info conflicts with other info? > > Vendors of client software sometimes give themselves a root cert in the > client, or at least have a close relationship with some of their CAs. > There's a lot of money at stake, how eager will they be to allow sites to > opt-out of that trust? Some of them also sell TLS MitM interception > products. > > The possibility that the bulk of clients will respect DNSSEC records which > cut their CAs out of the trust equation any time soon seems a bit remote. We > might as well be discussing the deprecation of SSLv3. It could happen > eventually, but probably not in the near term. > > In the meantime, we'd end up with the DNS root effectively having the power > of yet another CA. Except that it's not, because the various arms of ICANN > and VeriSign/Symantec are probably already trusted many times over. > > I've seen it said that during the pre-deployment phase, the designers and > promoters of DNSSEC denied they were making a replacement PKI. But the > discussion now is to what extent it is inevitable. Regardless, if this is > PKI 2.0 getting ready to usurp the throne, we should at least ensure that > its a legitimately designed trust model this time rather than stumbling into > whatever serves to enable some set of business agreements. > > - Marsh > -- Website: http://hallambaker.com/ --000e0cdf8c9087491b0491ae0c6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The attack surface is the number of paths that are open to an attacker.=A0<= div>
In the current model there is only one trust path, the P= KIX path.

In the new model, the attacker has a cho= ice of trust paths, the PKIX path and the DNSSEC path and they can attack e= ither of them.

The problem with the DNSSEC path is that it is vulnerab= le to attacks against the information input to the DNS system. The weakest = link there is the safeguards on registration of the DNS names.=A0


I think that whenever a proposal of this type= is brought that we should be told all the considerations and all the event= s that are motivating the design.



On Sat, Oct 2, 2010 at 9:49 PM, Marsh Ray <marsh@extendedsubset.com> wr= ote:
On 10/02/2010 03:16 PM, Ben Laurie wrote:
On 1 October 2010 16:15, Phillip Hallam-Baker<hallam@gmail.com> =A0wrote:

The problem with that approach is that the attacker now has two
infrastructures that they can attack rather than just one.

If I deploy the DNS solution, stating that DNS is authoritative, then
my attack surface now excludes all CAs. How is that an increase in
attack surface?

Contrast with today's situation, where my attack surface is increased on a regular basis by the introduction of new CAs, without any
consultation with me at all.

The thing we have to to keep in mind here is that this "attack surface= " is largely determined on the client of the equation. In other words,= if you attempt to set policy through DNS, it only applies to clients who c= hoose to respect it. And clients do have that annoying habit of not consult= ing the server admins (or the users for that matter) before changing their = trust. We can blame Netscape, they intentionally set it up this way (and ar= e no longer around to defend themselves).

How much consistency is there in the current crop of PKI rules? What if DNS= SEC info conflicts with other info?

Vendors of client software sometimes give themselves a root cert in the cli= ent, or at least have a close relationship with some of their CAs. There= 9;s a lot of money at stake, how eager will they be to allow sites to opt-o= ut of that trust? Some of them also sell TLS MitM interception products.
The possibility that the bulk of clients will respect DNSSEC records which = cut their CAs out of the trust equation any time soon seems a bit remote. W= e might as well be discussing the deprecation of SSLv3. It could happen eve= ntually, but probably not in the near term.

In the meantime, we'd end up with the DNS root effectively having the p= ower of yet another CA. Except that it's not, because the various arms = of ICANN and VeriSign/Symantec are probably already trusted many times over= .

I've seen it said that during the pre-deployment phase, the designers a= nd promoters of DNSSEC denied they were making a replacement PKI. But the d= iscussion now is to what extent it is inevitable. Regardless, if this is PK= I 2.0 getting ready to usurp the throne, we should at least ensure that its= a legitimately designed trust model this time rather than stumbling into w= hatever serves to enable some set of business agreements.

- Marsh



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

--000e0cdf8c9087491b0491ae0c6c-- From fanf2@hermes.cam.ac.uk Sun Oct 3 05:15:29 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0133A6C50; Sun, 3 Oct 2010 05:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-1.463, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO0E0Vy4UUv5; Sun, 3 Oct 2010 05:15:23 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id BEE7B3A6BD7; Sun, 3 Oct 2010 05:15: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 [87.115.122.141] (port=57857 helo=[192.168.1.5]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1P2NUB-0007M5-Yp (Exim 4.72) (return-path ); Sun, 03 Oct 2010 13:16:12 +0100 References: <1285970705.1984.136.camel@mattlaptop2.local> <4CA7E120.6080701@extendedsubset.com> In-Reply-To: <4CA7E120.6080701@extendedsubset.com> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8B117) From: Tony Finch Date: Sun, 3 Oct 2010 13:15:54 +0100 To: Marsh Ray Sender: Tony Finch X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: Phillip Hallam-Baker , "dnsop@ietf.org" , "saag@ietf.org" , "pkix@ietf.org" , "tls@ietf.org" Subject: Re: [saag] [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 12:15:30 -0000 On 3 Oct 2010, at 02:49, Marsh Ray wrote: >=20 > In the meantime, we'd end up with the DNS root effectively having the powe= r of yet another CA. Except that it's not, because the various arms of ICANN= and VeriSign/Symantec are probably already trusted many times over. I agree with your points about the difficulty of rolling out DNSSEC key assu= rance and its coexistence with PKIX. But the above is a bit off-base, because the DNS has a lot of structural con= straints that make it weaker than a CA. Although in theory the root zone ope= rators could steal any arbitrary name, the organisational checks and balance= s prevent that. CAs have no significant external checks and balances. For ex= ample they don't have the equivalent of whois that allows third parties to c= heck who has been issued a certificate for a particular name. Tony. -- f.anthony.n.finch http://dotat.at/ From hallam@gmail.com Sun Oct 3 08:13:34 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A11E3A6CE1; Sun, 3 Oct 2010 08:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.184, 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 6D8RsKsaC8TE; Sun, 3 Oct 2010 08:13:32 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 239C53A6CD8; Sun, 3 Oct 2010 08:13:30 -0700 (PDT) Received: by wyi11 with SMTP id 11so4996012wyi.31 for ; Sun, 03 Oct 2010 08:14: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; bh=KcCRwUdhKfFk38z3+dN7361oBbuTFWY+e52RJqx+GAk=; b=XG/eRqs6wv8hHUeSLbTIwWKs0gLOfMD/NKqzqAX5xveT4D03l8Q3vM2zSQ8qIEyzxj YJBGP4gztobM9tOODN1lpNIZ/44DRiASws6ArKurZuO0a2Q8sOCiOpRi3VzoNCLjCj4/ ULcou8iLgsCF5c+m1CbpV9eMmzI/5X/Y/EvNA= 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=QpzJQSIIG8LoXGSH0Nrk6gZtw9tt/MbS1St5F3cHrvgpyue/7Qy3Gci4HKy5BxyFdR y0PHFuGeNbKw2KovYUFNrHNpjIRFY3LwKEHFWbM9IN1jAyChdq5eXO9P+nJ8QApHfLSO O4NveynSccvCiAHW38giEbbbryprjm0o4fyQU= MIME-Version: 1.0 Received: by 10.216.59.131 with SMTP id s3mr6605073wec.71.1286118863280; Sun, 03 Oct 2010 08:14:23 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Sun, 3 Oct 2010 08:14:23 -0700 (PDT) In-Reply-To: References: <1285970705.1984.136.camel@mattlaptop2.local> <4CA7E120.6080701@extendedsubset.com> Date: Sun, 3 Oct 2010 11:14:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=000e0cd72042fc20c80491b7e1e2 X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: "dnsop@ietf.org" , Marsh Ray , "saag@ietf.org" , "pkix@ietf.org" , "tls@ietf.org" Subject: Re: [saag] [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 15:13:34 -0000 --000e0cd72042fc20c80491b7e1e2 Content-Type: text/plain; charset=ISO-8859-1 If the problem is the lack of checks and balances, the solution should be to introduce checks and balances. Moving from a market based solution with multiple CAs to a monopoly with one trust provider does not help at all. It makes the situation much worse because there is now no possibility of choice in the future. This type of decision needs to be taken in the open with the proposers clearly stating what they are about. The proposed charter as written misleads the reader into thinking that what is being proposed is to use the DNSSEC to provide one ADDITIONAL trust provider. What is actually being proposed is to replace the fifteen year established system of CAs with a new scheme starting in November. If you read through the KEYASSURE archives, you will find that whenever the proposers of this scheme are asked questions that they avoid answering them. Most often they claim not to understand what is being asked. I really don't think that we want to replace the existing infrastructure a new PKI designed by people who claim not to understand the issues involved. As the proposers of this scheme have done repeatedly. This whole thing is being hurried through as if the proposers know that if people actually stop and look at what is really being proposed that they know the whole proposal will collapse. Before we go any further with this, I want full disclosure. I want to know the full extent of what is being proposed. I also want to know anything else that might affect the consideration of this proposal. The reaction to asking legitimate security questions has been really rather awful. Whenever I ask a question, Paul Hoffman has immediately popped up to claim that nobody can understand it, apparently in an attempt to divert examination of the question into a flame war. I do not think it is legitimate for a group of people to bully and threaten away those of contrary views and then declare that they have achieved 'consensus'. That is the way Trotskyites take over political parties, they call it 'entryism'. On Sun, Oct 3, 2010 at 8:15 AM, Tony Finch wrote: > On 3 Oct 2010, at 02:49, Marsh Ray wrote: > > > > In the meantime, we'd end up with the DNS root effectively having the > power of yet another CA. Except that it's not, because the various arms of > ICANN and VeriSign/Symantec are probably already trusted many times over. > > I agree with your points about the difficulty of rolling out DNSSEC key > assurance and its coexistence with PKIX. > > But the above is a bit off-base, because the DNS has a lot of structural > constraints that make it weaker than a CA. Although in theory the root zone > operators could steal any arbitrary name, the organisational checks and > balances prevent that. CAs have no significant external checks and balances. > For example they don't have the equivalent of whois that allows third > parties to check who has been issued a certificate for a particular name. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > > -- Website: http://hallambaker.com/ --000e0cd72042fc20c80491b7e1e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If the problem is the lack of checks and balances, the solution should be t= o introduce checks and balances.

Moving from a market ba= sed solution with multiple CAs to a monopoly with one trust provider does n= ot help at all. It makes the situation much worse because there is now no p= ossibility of choice in the future.


This type of decision needs to be taken = in the open with the proposers clearly stating what they are about. The pro= posed charter as written misleads the reader into thinking that what is bei= ng proposed is to use the DNSSEC to provide one ADDITIONAL trust provider.<= /div>

What is actually being proposed is to replace the fifte= en year established system of CAs with a new scheme starting in November.


If you read through the KEYASSURE ar= chives, you will find that whenever the proposers of this scheme are asked = questions that they avoid answering them. Most often they claim not to unde= rstand what is being asked.=A0

I really don't think that we want to replace the ex= isting infrastructure a new PKI designed by people who claim not to underst= and the issues involved. As the proposers of this scheme have done repeated= ly.=A0

This whole thing is being hurried through as if the pro= posers know that if people actually stop and look at what is really being p= roposed that they know the whole proposal will collapse.


Before we go any further with this, I want full d= isclosure. I want to know the full extent of what is being proposed. I also= want to know anything else that might affect the consideration of this pro= posal.=A0

The reaction to asking legitimate security questions ha= s been really rather awful. Whenever I ask a question, Paul Hoffman has imm= ediately popped up to claim that nobody can understand it, apparently in an= attempt to divert examination of the question into a flame war.

I do not think it is legitimate for a group of people t= o bully and threaten away those of contrary views and then declare that the= y have achieved 'consensus'. That is the way Trotskyites take over = political parties, they call it 'entryism'.


On Sun, Oct 3= , 2010 at 8:15 AM, Tony Finch <dot@dotat.at> wrote:
On 3 Oct 2010, at 02:49, Marsh Ray <marsh@extendedsubset.com> wrote:
>
> In the meantime, we'd end up with the DNS root effectively having = the power of yet another CA. Except that it's not, because the various = arms of ICANN and VeriSign/Symantec are probably already trusted many times= over.

I agree with your points about the difficulty of rolling out DNSSEC k= ey assurance and its coexistence with PKIX.

But the above is a bit off-base, because the DNS has a lot of structural co= nstraints that make it weaker than a CA. Although in theory the root zone o= perators could steal any arbitrary name, the organisational checks and bala= nces prevent that. CAs have no significant external checks and balances. Fo= r example they don't have the equivalent of whois that allows third par= ties to check who has been issued a certificate for a particular name.

Tony.
--
f.anthony.n.finch =A0<dot@dotat.at&g= t; =A0http://dotat.at/



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

--000e0cd72042fc20c80491b7e1e2-- From fanf2@hermes.cam.ac.uk Sun Oct 3 09:10:13 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 237D33A6D70; Sun, 3 Oct 2010 09:10:13 -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=[AWL=-1.394, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HZYe-tdRMDC; Sun, 3 Oct 2010 09:10:09 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 8CCB33A6CE2; Sun, 3 Oct 2010 09:10:06 -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 [87.115.122.141] (port=58347 helo=[192.168.1.5]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1P2R9N-0004Nu-rx (Exim 4.72) (return-path ); Sun, 03 Oct 2010 17:10:58 +0100 References: <1285970705.1984.136.camel@mattlaptop2.local> <4CA7E120.6080701@extendedsubset.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <63650FE8-08F0-4EF4-9F5F-2348DB9AB9FA@dotat.at> X-Mailer: iPhone Mail (8B117) From: Tony Finch Date: Sun, 3 Oct 2010 17:10:39 +0100 To: Phillip Hallam-Baker Sender: Tony Finch X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: "dnsop@ietf.org" , Marsh Ray , "saag@ietf.org" , "pkix@ietf.org" , "tls@ietf.org" Subject: Re: [saag] [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 16:10:14 -0000 On 3 Oct 2010, at 16:14, Phillip Hallam-Baker wrote: >=20 > Moving from a market based solution with multiple CAs to a monopoly with o= ne trust provider does not help at all. It makes the situation much worse be= cause there is now no possibility of choice in the future. It has the advantage of preventing a race to the bottom. Note that there is a fair amount of choice available at lower levels in the D= NS. So long as the registry provides a secure infrastructure, customers of s= ecure registrars need not be concerned that insecure registrars can steal th= eir names. There is no similar regulation of CAs. Tony. -- f.anthony.n.finch http://dotat.at/= From hallam@gmail.com Sun Oct 3 15:11:49 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8273A6EBB for ; Sun, 3 Oct 2010 15:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.182, 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 kjkmDmt6lN5k for ; Sun, 3 Oct 2010 15:11:46 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 38D703A6EBA for ; Sun, 3 Oct 2010 15:11:46 -0700 (PDT) Received: by wwj40 with SMTP id 40so2442705wwj.13 for ; Sun, 03 Oct 2010 15:12:39 -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=YGdhJd/FQeb9CrRJoJSeABXB34HqbZMS2p0L8XBuDLU=; b=AdJhdjYOB028OkNka9DNdTgR6j/TP81UqN4jAH1TNuPER1str2inD4el4yCxKi4fua PF4igfDWc9TrX7nSeUIqNsH+iquS1tLiXk6Xm5BjgyfeWOlVIPyXnS7MGwdmVIT4hueF y0hSLj6uTv1/WPIhix4DenG0jZenhQ9GhxNCs= 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=VQb+kmG6T+aD1VTCaufyl9wMSYnzG6NekfOjx1gr2yovoCBe2rND7iGbTBBcua7H11 GMfKHnnIecwl3XtUgkguQdYX+0S25TxunnaAMwW7MEaVRLi+8vzGvIDgzHSwnU3Mogml QrJ4DlnAM2FdEVMf+iOlGZ1tA3IOxNFaDRjcY= MIME-Version: 1.0 Received: by 10.216.180.200 with SMTP id j50mr4473601wem.36.1286143959061; Sun, 03 Oct 2010 15:12:39 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Sun, 3 Oct 2010 15:12:39 -0700 (PDT) In-Reply-To: References: <4CA65AD7.80300@ieca.com> <4CA8ECA9.9020201@gondrom.org> Date: Sun, 3 Oct 2010 18:12:39 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016367facebcf53430491bdb98c X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 22:11:49 -0000 --0016367facebcf53430491bdb98c Content-Type: text/plain; charset=ISO-8859-1 Given the uncertainty surrounding the SHA-2 construction, use of the 512 bit version which has more rounds would appear prudent. Also, given that SHA-3 is going to arrive and have 256 and 512 bit versions, it is probably a good idea to start using the full name SHA2-256. On Sun, Oct 3, 2010 at 5:35 PM, Paul Hoffman wrote: > At 9:50 PM +0100 10/3/10, Tobias Gondrom wrote: > > Must say I agree with Paul's concerns below (and in particular > >hesitated too when I read the intended "MUST NOT" effect of a guidance > >informational draft on standards documents). > >However, I think the general idea to write a guidance ID is a good idea > >from Tim, et al. > > Fully agree (certainly more useful than such guidance coming from you or > I). However, it would be nice if the document said why they were the ones > writing it. > > >One further comment: I am a bit uncertain to why you refer to SHA-256 > >from the SHA-2 family only (and thus not mention/exclude SHA-512)? > > Because the IETF almost always deals only with 128-bit strength security, > and using SHA-384 or SHA-512 is just as waste of processor and network > resources in such cases. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Website: http://hallambaker.com/ --0016367facebcf53430491bdb98c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given the uncertainty surrounding the SHA-2 construction, use of the 512 bi= t version which has more rounds would appear prudent.

Al= so, given that SHA-3 is going to arrive and have 256 and 512 bit versions, = it is probably a good idea to start using the full name SHA2-256.

On Sun, Oct 3, 2010 at 5:35 PM, Paul Hoffman= <paul.hoffma= n@vpnc.org> wrote:
At 9:50 PM +0100 10/3/10, Tobias Gondrom wrote:
> Must say I agree with Paul's concerns below (and in particular
>hesitated too when I read the intended "MUST NOT" effect of a= guidance
>informational draft on standards documents).
>However, I think the general idea to write a guidance ID is a good idea=
>from Tim, et al.

Fully agree (certainly more useful than such guidance coming from you= or I). However, it would be nice if the document said why they were the on= es writing it.

>One further comment: I am a bit uncertain to why you refer to SHA-256 >from the SHA-2 family only (and thus not mention/exclude SHA-512)?

Because the IETF almost always deals only with 128-bit strength secur= ity, and using SHA-384 or SHA-512 is just as waste of processor and network= resources in such cases.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag



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

--0016367facebcf53430491bdb98c-- From mrex@sap.com Mon Oct 4 07:36:41 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676433A6FC4; Mon, 4 Oct 2010 07:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.836 X-Spam-Level: X-Spam-Status: No, score=-9.836 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHMoG11GZj5U; Mon, 4 Oct 2010 07:36:40 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 3531E3A6FBE; Mon, 4 Oct 2010 07:36:38 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o94EbUkK001001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Oct 2010 16:37:30 +0200 (MEST) From: Martin Rex Message-Id: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Mon, 4 Oct 2010 16:37:29 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Oct 2, 10 11:30:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:38 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org, marsh@extendedsubset.com Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 14:36:41 -0000 Phillip Hallam-Baker wrote: > > The attack surface is the number of paths that are open to an attacker. > > In the current model there is only one trust path, the PKIX path. > > In the new model, the attacker has a choice of trust paths, the PKIX path > and the DNSSEC path and they can attack either of them. The PKI-based attack surface includes each and every single CA that is signed under one of the existing >100 pre-configured trust anchors shipping with browsers. An attacker is free to choose to attack any single one of these CAs and/or their issuing/validation procedures. Trusting Certificates that are distributed under protection of DNSSEC would amount to one additional trust anchor. > > The problem with the DNSSEC path is that it is vulnerable to attacks against > the information input to the DNS system. The weakest link there is the > safeguards on registration of the DNS names. It seems that you do not realize that the entire TLS PKI security model, as far as the automatic / no-prompt "server endpoint identification" is concerned, has always been relying completely on that DNS data being accurate. Therefore, security-wise, trusting Certificates that are distributed through DNSSEC for no-prompt server endpoint identification is more secure than the TLS PKI pre-configured trusted scheme, and it does not add any new attack surface. Only when server certificates are manually verified by end users, other information from these certificates besides the DNS f.q.d.n might be considered in the end users decision to trust a server cert. But keep in mind that few TLS clients (such as browsers), currently support "pinning" of PKIX-authenticated server certs, so that on future connects only the very same server cert (with user-authenticated attributes other than DNS f.q.d.n) will be accepted from that server. In is very common misbehaviour in TLS clients to accept arbitrary other server certs on future connects, as long as the DNS f.q.d.n matches. One thing that needs to be addressed/solved is the key/cert rollover for any TLS-Server, so that it is possible to list more than one server cert as "valid" for a Server through DNS, at least for the time of the transition/rollover. -Martin From marsh@extendedsubset.com Mon Oct 4 08:13:19 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94763A6FEC; Mon, 4 Oct 2010 08:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.531, 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 211YBrjouAxH; Mon, 4 Oct 2010 08:13:08 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 179093A6FD0; Mon, 4 Oct 2010 08:11:27 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1P2miF-000Gpx-CG; Mon, 04 Oct 2010 15:12:23 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2327D6018; Mon, 4 Oct 2010 15:12:21 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/RqO921MeCtQuFarZ58MlTmiUgl0nkbFs= Message-ID: <4CA9EED5.5050006@extendedsubset.com> Date: Mon, 04 Oct 2010 10:12:21 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: mrex@sap.com References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> In-Reply-To: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, Phillip Hallam-Baker , saag@ietf.org, tls@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 15:13:19 -0000 On 10/04/2010 09:37 AM, Martin Rex wrote: > Phillip Hallam-Baker wrote: >> >> The problem with the DNSSEC path is that it is vulnerable to attacks against >> the information input to the DNS system. The weakest link there is the >> safeguards on registration of the DNS names. > > It seems that you do not realize that the entire TLS PKI security model, > as far as the automatic / no-prompt "server endpoint identification" is > concerned, has always been relying completely on that DNS data being > accurate. How do you figure that? I can put an entry in /etc/hosts (do this all the time for testing) and DNS isn't even queried. Yet the server certificate is validated as usual. > But keep in mind that few TLS clients (such as browsers), currently > support "pinning" of PKIX-authenticated server certs, so that on future > connects only the very same server cert (with user-authenticated > attributes other than DNS f.q.d.n) will be accepted from that server. > In is very common misbehaviour in TLS clients to accept arbitrary other > server certs on future connects, as long as the DNS f.q.d.n matches. Is there a spec saying this is invalid behavior? > One thing that needs to be addressed/solved is the key/cert rollover > for any TLS-Server, so that it is possible to list more than one > server cert as "valid" for a Server through DNS, at least for the > time of the transition/rollover. If you're going to trust certs you get out of DNS, you might as well just put a self-signed organizational CA cert in there. Maybe that's what's being proposed. Say, what's the link to the Internet Draft proposal we're discussing anyway? - Marsh From mrex@sap.com Mon Oct 4 09:18:26 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40DCA3A6FED; Mon, 4 Oct 2010 09:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.841 X-Spam-Level: X-Spam-Status: No, score=-9.841 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F8kVK7DF86O; Mon, 4 Oct 2010 09:18:25 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E85E83A6CAB; Mon, 4 Oct 2010 09:18:24 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o94GJHi1008108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Oct 2010 18:19:17 +0200 (MEST) From: Martin Rex Message-Id: <201010041619.o94GJFXF006308@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Mon, 4 Oct 2010 18:19:15 +0200 (MEST) In-Reply-To: <4CA9EED5.5050006@extendedsubset.com> from "Marsh Ray" at Oct 4, 10 10:12:21 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:38 -0700 Cc: mrex@sap.com, dnsop@ietf.org, saag@ietf.org, pkix@ietf.org, hallam@gmail.com, tls@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:18:26 -0000 Marsh Ray wrote: > > On 10/04/2010 09:37 AM, Martin Rex wrote: > > > > It seems that you do not realize that the entire TLS PKI security model, > > as far as the automatic / no-prompt "server endpoint identification" is > > concerned, has always been relying completely on that DNS data being > > accurate. > > How do you figure that? > > I can put an entry in /etc/hosts (do this all the time for testing) and > DNS isn't even queried. Yet the server certificate is validated as usual. In order to get a TLS server cert issued for a particular DNS f.q.d.n under most of the existing pre-configured trust anchors, you only need to provide some vague proof that you leased that DNS domain. The no-prompt server endpoint identification will ignore any information in the cert besides the DNS f.q.d.n, no matter how carefully that other part of information may be validated. > > > But keep in mind that few TLS clients (such as browsers), currently > > support "pinning" of PKIX-authenticated server certs, so that on future > > connects only the very same server cert (with user-authenticated > > attributes other than DNS f.q.d.n) will be accepted from that server. > > In is very common misbehaviour in TLS clients to accept arbitrary other > > server certs on future connects, as long as the DNS f.q.d.n matches. > > Is there a spec saying this is invalid behavior? No. For the existing specs, this issue fell into the huge "out-of-scope" gaps between rfc-2818, PKIX and TLS. I know there is a school of thought popular in the US that is build around "but it didn't come with a warning label that I must not shoot in my foot, so it isn't my fault". I assume that _very_ few of those TLS-enabled servers that offer TLS client cert authentication, base their authorization decision on only one particular certificate attribute and ignore all the rest of the certificate and allow it to chain to arbitrary CAs operated under any one of >100 pre-configured trust anchors. But for the server side, no-prompting usability has always been deemed MUCH more important than security. > > > One thing that needs to be addressed/solved is the key/cert rollover > > for any TLS-Server, so that it is possible to list more than one > > server cert as "valid" for a Server through DNS, at least for the > > time of the transition/rollover. > > If you're going to trust certs you get out of DNS, you might as well > just put a self-signed organizational CA cert in there. Maybe that's > what's being proposed. That only affects the frequency of the key/cert rollover, not the fact that key/cert rollover needs to be addressed. Distributing an organizations CA cert through DNS instead of the server certs is somewhat incompatible with how a lot of traditional PKI software works (like Microsoft's CryptoAPI on XP/2003). PKIX specs define certificate path validation only when you have a certificate chain to one of your trust anchors. You probably will _NOT_ want most of these CAs a trust anchor, even when you might allow the use of such organizational CA certs for verification of specific server certificates. I once received an S/Mime signed Email in Outlook 2003, and the signature included an end-entity and an intermediateCA cert. I found myself unable to make Outlook verify the digital signature of that Email, because of a lack of the (non-public, organizational) RootCA cert for that chain. > > Say, what's the link to the Internet Draft proposal we're discussing anyway? To me it sounded like it is a post-prototype implementation, pre-draft discussion about the charter of the "keyassurance" WG. -Martin From jakob@kirei.se Mon Oct 4 10:29:18 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853E13A6FB7 for ; Mon, 4 Oct 2010 10:29: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=[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 Lo+9FxLeKJNU for ; Mon, 4 Oct 2010 10:29:17 -0700 (PDT) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 0BFEE3A6FF8 for ; Mon, 4 Oct 2010 10:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=jaCwyOcC9hEjDhT/H08gA+3xSDdycBGuhcKZ4APBQkY=; b=i5xIKSzHE6OAXzEL0hK2eZ9reAyUrFAzSGVZPfADNjI+Op1O8AXm2wzl42Nw/BZx81gMcFihifU6Z igu9DTyfgQi4iEOm2rGl6RLsVQEdMampq2LKKAV36rU8OaabK0JQOgZMmd7cLwS+AM3mGhGea4jJjQ VXpKR5EZh836Q5uE= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 4 Oct 2010 19:30:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <4CA9EED5.5050006@extendedsubset.com> Date: Mon, 4 Oct 2010 19:29:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0E1A93AF-B02F-4744-A62C-08175DCA2A2B@kirei.se> References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> <4CA9EED5.5050006@extendedsubset.com> To: Marsh Ray X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: mrex@sap.com, dnsop@ietf.org, saag@ietf.org, pkix@ietf.org, Phillip Hallam-Baker , tls@ietf.org Subject: Re: [saag] [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 17:29:18 -0000 On 4 okt 2010, at 17.12, Marsh Ray wrote: > Say, what's the link to the Internet Draft proposal we're discussing = anyway? https://datatracker.ietf.org/doc/draft-hoffman-keys-linkage-from-dns/, = among others. j From mstjohns@comcast.net Mon Oct 4 11:30:30 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118DD3A704F for ; Mon, 4 Oct 2010 11:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.334 X-Spam-Level: X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 RwKhIAfN9zpD for ; Mon, 4 Oct 2010 11:29:58 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id 9E23A3A705F for ; Mon, 4 Oct 2010 11:29:35 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta13.westchester.pa.mail.comcast.net with comcast id EcPk1f0020vyq2s5DiWXZd; Mon, 04 Oct 2010 18:30:31 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta05.westchester.pa.mail.comcast.net with comcast id EiWX1f0031EtFYL3RiWX1e; Mon, 04 Oct 2010 18:30:31 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 Oct 2010 14:30:29 -0400 To: pkix@ietf.org,dnsop@ietf.org,saag@ietf.org,tls@ietf.org From: Michael StJohns In-Reply-To: <4CA9EED5.5050006@extendedsubset.com> References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> <4CA9EED5.5050006@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20101004182935.9E23A3A705F@core3.amsl.com> X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 18:30:30 -0000 Hi - DNSSEC seems to be picking on PKIX and vice versa - maybe the right answer is both? DNSSEC provides a "secure" association FROM the name TO the IP address. But the DNS domain owner tends not to be the host owner so this asserted association may not reflect the intent of the host owner. Also, DNSSEC doesn't protect from IP hijacking (re-routing). PKIX provides a "secure" association TO/FROM "a" name to a public key. The host owner holds the private key and can prove "ownership" of the related public key. But the host owner tends not to be the domain owner so the asserted association may not reflect the intent of the DNS domain owner. What if - the PKIX certificate for the host contained a "permit" for the name signed by the DNS owner? A signature over the hash of the public key in the certificate, and the DNS name - and maybe some expiration info verifiable by the data in DNSSEC? The path goes something like: 1) Use DNS and DNSSEC to find the host (or even just DNS) 2) Use TLS to grab the certificate 3) Verify the certificate using the PKIX path to a trust anchor 4) Verify the host knows the private key related to the host certificate 5) Verify the extension in the certificate was signed by the domain's DNSSEC key (pick one of special key, KSK or ZSK) 6) Verify the name offered in the certificate matches the DNS name looked up. You've verified that: a) The zone owner has assigned the name to the owner of the cert's private key b) The host owner has agreed the host has the DNS name. c) The IP to Name mapping (what might be in the PTR record and signed under DNSSEC - maybe). The DNSSEC name to IP address mapping becomes irrelevant for trust purposes which means that IP hijacking is no longer an issue. A random PKIX forming a certificate with a DNS name in it can't form one that proves the name assignment from the DNS, so the large set of PKIX trust anchors becomes less of an issue. Mike From mstjohns@comcast.net Mon Oct 4 11:30:30 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11AD33A7054 for ; Mon, 4 Oct 2010 11:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.334 X-Spam-Level: X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 3mayWO1dDKHE for ; Mon, 4 Oct 2010 11:29:58 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id 97D183A705C for ; Mon, 4 Oct 2010 11:29:35 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta13.westchester.pa.mail.comcast.net with comcast id EgRF1f0030vyq2s5DiWXZc; Mon, 04 Oct 2010 18:30:31 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta05.westchester.pa.mail.comcast.net with comcast id EiWX1f0031EtFYL3RiWX1e; Mon, 04 Oct 2010 18:30:31 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 Oct 2010 14:30:29 -0400 To: pkix@ietf.org,dnsop@ietf.org,saag@ietf.org,tls@ietf.org From: Michael StJohns In-Reply-To: <4CA9EED5.5050006@extendedsubset.com> References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> <4CA9EED5.5050006@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20101004182935.97D183A705C@core3.amsl.com> X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 18:30:30 -0000 Hi - DNSSEC seems to be picking on PKIX and vice versa - maybe the right answer is both? DNSSEC provides a "secure" association FROM the name TO the IP address. But the DNS domain owner tends not to be the host owner so this asserted association may not reflect the intent of the host owner. Also, DNSSEC doesn't protect from IP hijacking (re-routing). PKIX provides a "secure" association TO/FROM "a" name to a public key. The host owner holds the private key and can prove "ownership" of the related public key. But the host owner tends not to be the domain owner so the asserted association may not reflect the intent of the DNS domain owner. What if - the PKIX certificate for the host contained a "permit" for the name signed by the DNS owner? A signature over the hash of the public key in the certificate, and the DNS name - and maybe some expiration info verifiable by the data in DNSSEC? The path goes something like: 1) Use DNS and DNSSEC to find the host (or even just DNS) 2) Use TLS to grab the certificate 3) Verify the certificate using the PKIX path to a trust anchor 4) Verify the host knows the private key related to the host certificate 5) Verify the extension in the certificate was signed by the domain's DNSSEC key (pick one of special key, KSK or ZSK) 6) Verify the name offered in the certificate matches the DNS name looked up. You've verified that: a) The zone owner has assigned the name to the owner of the cert's private key b) The host owner has agreed the host has the DNS name. c) The IP to Name mapping (what might be in the PTR record and signed under DNSSEC - maybe). The DNSSEC name to IP address mapping becomes irrelevant for trust purposes which means that IP hijacking is no longer an issue. A random PKIX forming a certificate with a DNS name in it can't form one that proves the name assignment from the DNS, so the large set of PKIX trust anchors becomes less of an issue. Mike From hallam@gmail.com Mon Oct 4 11:51:46 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2320C3A7060; Mon, 4 Oct 2010 11:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YHf4tMwDf4tV; Mon, 4 Oct 2010 11:51:43 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 3A9DD3A7003; Mon, 4 Oct 2010 11:51:42 -0700 (PDT) Received: by wwj40 with SMTP id 40so3258969wwj.13 for ; Mon, 04 Oct 2010 11:52:37 -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=I3lUvKSRyItTF2en5jtBOjGAwODcJJq0hzJkFtdzR/g=; b=AwsG807XXqD5nOiqjUBgw4UQSAo3wPVYp0a8tZP3jJiFLIL/fEuWUg4UwuD1xMWw8Z m9yVCw/kwfgW/fEFWN8BgVNU3h2019W8YDS0sxymSK3jTsI9Soz0h9afqSLFYkVJkH5B OVDPfNT4AG8VLoteuqBQfa6NMqON2YBGRxDJA= 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=S5lApjMLl+Eoqz+LBQBAGRdu4hGHMxAPVuzxqqAznwP/iP+QqeMeyuftqn3VoQ4Wd5 H0kkEHV6Pr3L5HcjIvAAMAdD9KyAeSMrojgjNnbcV4xBaDeb2Ij+06oUy1vKuMMse0V5 sHqMHDpErxhS/dyb420uZjzAtxjc54gTfZXUk= MIME-Version: 1.0 Received: by 10.216.0.76 with SMTP id 54mr8106423wea.49.1286218357526; Mon, 04 Oct 2010 11:52:37 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Mon, 4 Oct 2010 11:52:37 -0700 (PDT) In-Reply-To: <4CAA00EF.2040107@nic.cz> References: <4CAA00EF.2040107@nic.cz> Date: Mon, 4 Oct 2010 14:52:37 -0400 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= Content-Type: multipart/alternative; boundary=001485f626f04dd22d0491cf0cd1 X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, tls@ietf.org, saag@ietf.org Subject: Re: [saag] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 18:51:46 -0000 --001485f626f04dd22d0491cf0cd1 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable The reason I did so was that I did not believe that the initial presentatio= n of KEYASSURE to the wider Internet community gave an accurate or full description of what the intended proposal was. Since neither of the proposers took any notice of my repeated requests to correct this situation, I decided that it was time to do so myself. My original understanding from the announcement made was that 'assurance' meant to provide additional mechanisms for binding keys to DNS names. It ha= s since turned out that what is being proposed is very different and has significant impact across the whole IETF security area. My problem with KEYASSURE is precisely the fact that people have not been given the 'full picture'. Even now after three drafts, the key-linkage draft does not actualy specify that the purpose of the protocol is to enable a site to specify which certificates are valid for the site by enumeration of all valid certs. That is merely an unremarked consequence of the algorithm. 2010/10/4 Ond=F8ej Sur=FD > Phillip, > > you present your views by cross-posting several other IETF mailing list > without posting this to keyassure@ietf.org. This doesn't give potential > readers full picture about what's happening in the keyassure and what is = the > general consensus in the list. > > So please all - if you want to respond to Phillip's message, first go to > keyassure mailing list archive[1], then join the the list[2] and comment > there. I don't think we want to fill our inboxes with this discussion > (which should really happen in keyassure) in several copies. > > While we value input from other working groups it is already hard to foll= ow > the discussion in one mailing list and when it splits to many, it will be > just a mess. > > Ondrej > > 1. http://www.ietf.org/mail-archive/web/keyassure/ > 2. https://www.ietf.org/mailman/listinfo/keyassure > > > On 1.10.2010 17:29, Phillip Hallam-Baker wrote: > >> For the past month I have been participating in the KEYASSURE discussion= s. >> >> One aspect of those discussions that was not made clear in the original >> notice sent out is that the group is not only considering key assurance, >> the proposals made are also intended to have security policy semantics. >> >> This was not apparent to me from reading the list announcement, the >> initial proposed charter or the Internet drafts. I have asked the >> organizers of the group to clarify the matter in the wider IETF >> community but they have not done so. >> >> >> In particular I am very concerned about the particular approach being >> taken to security policy. What the proposers are attempting to do is to >> create a mechanism that allows a site that only uses one particular high >> assurance CA to 'protect' themselves against SSL certificates being >> issued by low assurance CAs. >> >> As such, this is an objective I approve of and is one that I would like >> to see supported in a generalized security policy. It should be possible >> for a site to make security policy statements of the form 'all valid >> PKIX certs for example.com have cert X in the >> >> validation path'. >> >> >> What I object to is the approach being taken which is to use DNSSEC to >> replace PKIX certificate validation entirely. >> >> Now the proponents are trying to downplay this by saying that 'all' they >> are doing is to tell people to 'ignore' PKIX validation. But that >> approach really offends my sense of layering. >> >> Worse still, the proponents refuse to allow any method of shutting this >> system off. So if I have a site where I want to use DNSSEC validated >> certificates on the mail server, deployment is going to impact my Web >> server. >> >> >> Specifically the proposal amounts to using the DNS CERT record to >> publish a fingerprint of all the certificates permitted for use with TLS >> at a specific domain: >> >> example.com CERT TLSFP 0 0 >> example.com CERT TLSFP 0 0 >> >> >> It is proposed to replace current TLS certificate processing semantics >> with the following: >> >> 1) Query for CERT record at example.com >> >> 2) If no CERT record with TLSFP certificate type exists then perform >> normal PKIX validation and return that result >> 3) Otherwise attempt to match the TLS end entity certificate with one of >> the fingerprints specified in the published TLSFP RRs >> 4) If a match is found return VALID, otherwise return INVALID >> >> Note here that if there is a TLSFP RR that it takes precedence over PKIX >> processing rules. >> >> There should of course be DNSSEC validation performed in that process as >> well, but the authors have not explained how that is meant to work in >> the context of their proposal so I left it out. >> >> >> The defenses made for this approach are of the form 'you have to wear >> big pants to play this game'. In other words if people are going to >> administer these systems and not be burned they are going to have to >> understand what they are doing. I do not consider this a responsible >> approach to protocol design. >> >> What I would prefer is to have systems that do not need to be >> administered by people at all. That is not possible when the approach >> has hidden side effects that cannot be anticipated by scripts. >> >> >> I am very much committed to the idea of doing security policy. But this >> is not an approach I can support. Any policy mechanism has to be >> orthogonal to the key validation strategy in my view. I should be able >> to use any DNS security policy mechanism that the IETF endorses with >> PKIX certificate processing semantics. >> >> I have proposed an alternative approach in >> >> http://tools.ietf.org/html/draft-hallambaker-esrv-00 >> >> This does not currently contain a mechanism to express trust >> restrictions but is designed to be extensible to support such. When I >> proposed ESRV I was unaware that the KEYASSURE proposal was intended to >> have a security policy aspect at all. It is still not made explicit in >> their draft. >> >> >> Using the revised version of ESRV I am currently writing, a security >> policy of the form 'always use TLS with any protocol at example.com >> ' would have the form: >> >> example.com ESRV "tls=3Drequired" >> >> >> A security policy that was specific to http would be expressed as: >> >> example.com ESRV "prefix=3D_http._tcp" >> _http._tcp.example.com ESRV "tls=3Drequired" >> >> or >> >> example.com ESRV "prefix=3D*" >> _http._tcp.example.com ESRV "tls=3Drequired" >> >> >> The reason for this change from the -00 version is that this approach >> supports CNAMEs. >> >> >> The reason that I started with the requirement to use SSL is that >> security policy relating to trust criteria is meaningless until you have >> a statement that use of SSL is required. >> >> >> I have no objection to doing security policy. But I do have a real >> objection to an approach that negates PKIX semantics as the TLSFP >> approach does. >> >> >> -------- Original Message -------- >> Subject: New Non-WG Mailing List: keyassure -- Key Assurance With >> DNSSEC >> Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT) >> From: IETF Secretariat > > >> To: IETF Announcement list > > >> CC: keyassure@ietf.org , >> ondrej.sury@nic.cz , warren@kumari.net >> >> >> 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. >> >> >> -- >> 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 >> ------------------------------------------- >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> >> https://www.ietf.org/mailman/listinfo/saag >> >> >> >> >> -- >> Website: http://hallambaker.com/ >> >> > > -- > 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 > ------------------------------------------- > --=20 Website: http://hallambaker.com/ --001485f626f04dd22d0491cf0cd1 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable The reason I did so was that I did not believe that the initial presentatio= n of KEYASSURE to the wider Internet community gave an accurate or full des= cription of what the intended proposal was.

Since neithe= r of the proposers took any notice of my repeated requests to correct this = situation, I decided that it was time to do so myself.

My original understanding from the announcement made wa= s that 'assurance' meant to provide additional mechanisms for bindi= ng keys to DNS names. It has since turned out that what is being proposed i= s very different and has significant impact across the whole IETF security = area.


My problem with KEYASSURE is precisely t= he fact that people have not been given the 'full picture'.=A0

Even now after three drafts, the key-linkage draft doe= s not actualy specify that the purpose of the protocol is to enable a site = to specify which certificates are valid for the site by enumeration of all = valid certs. That is merely an unremarked consequence of the algorithm.


2010/10/4 Ond=F8ej Sur= =FD <ondrej.sury= @nic.cz>
Phillip,

you present your views by cross-posting several other IETF mailing list wit= hout posting this to keyassure@ietf.org. =A0This doesn't give potential readers full p= icture about what's happening in the keyassure and what is the general = consensus in the list.

So please all - if you want to respond to Phillip's message, first go t= o keyassure mailing list archive[1], then join the the list[2] and comment = there. =A0I don't think we want to fill our inboxes with this discussio= n (which should really happen in keyassure) in several copies.

While we value input from other working groups it is already hard to follow= the discussion in one mailing list and when it splits to many, it will be = just a mess.

Ondrej

1. http://www.ietf.org/mail-archive/web/keyassure/
2. https://www.ietf.org/mailman/listinfo/keyassure
=

On 1.10.2010 17:29, Phillip Hallam-Baker wrote:
For the past month I have been participating in the KEYASSURE discussions.<= br>
One aspect of those discussions that was not made clear in the original
notice sent out is that the group is not only considering key assurance, the proposals made are also intended to have security policy semantics.

This was not apparent to me from reading the list announcement, the
initial proposed charter or the Internet drafts. I have asked the
organizers of the group to clarify the matter in the wider IETF
community but they have not done so.


In particular I am very concerned about the particular approach being
taken to security policy. What the proposers are attempting to do is to
create a mechanism that allows a site that only uses one particular high assurance CA to 'protect' themselves against SSL certificates being=
issued by low assurance CAs.

As such, this is an objective I approve of and is one that I would like
to see supported in a generalized security policy. It should be possible for a site to make security policy statements of the form 'all valid
PKIX certs for example.com= <http://example.co= m> have cert X in the

validation path'.


What I object to is the approach being taken which is to use DNSSEC to
replace PKIX certificate validation entirely.

Now the proponents are trying to downplay this by saying that 'all'= they
are doing is to tell people to 'ignore' PKIX validation. But that approach really offends my sense of layering.

Worse still, the proponents refuse to allow any method of shutting this
system off. So if I have a site where I want to use DNSSEC validated
certificates on the mail server, deployment is going to impact my Web
server.


Specifically the proposal amounts to using the DNS CERT record to
publish a fingerprint of all the certificates permitted for use with TLS at a specific domain:

example.com <= http://example.com>= CERT TLSFP 0 0 <digest cert 1>
example.com <http://example.com> CERT = TLSFP 0 0 <digest cert 2>


It is proposed to replace current TLS certificate processing semantics
with the following:

1) Query for CERT record at example.com <http= ://example.com>

2) If no CERT record with TLSFP certificate type exists then perform
normal PKIX validation and return that result
3) Otherwise attempt to match the TLS end entity certificate with one of the fingerprints specified in the published TLSFP RRs
4) If a match is found return VALID, otherwise return INVALID

Note here that if there is a TLSFP RR that it takes precedence over PKIX processing rules.

There should of course be DNSSEC validation performed in that process as well, but the authors have not explained how that is meant to work in
the context of their proposal so I left it out.


The defenses made for this approach are of the form 'you have to wear big pants to play this game'. In other words if people are going to
administer these systems and not be burned they are going to have to
understand what they are doing. I do not consider this a responsible
approach to protocol design.

What I would prefer is to have systems that do not need to be
administered by people at all. That is not possible when the approach
has hidden side effects that cannot be anticipated by scripts.


I am very much committed to the idea of doing security policy. But this
is not an approach I can support. Any policy mechanism has to be
orthogonal to the key validation strategy in my view. I should be able
to use any DNS security policy mechanism that the IETF endorses with
PKIX certificate processing semantics.

I have proposed an alternative approach in

http://tools.ietf.org/html/draft-hallambaker-esrv-00

This does not currently contain a mechanism to express trust
restrictions but is designed to be extensible to support such. When I
proposed ESRV I was unaware that the KEYASSURE proposal was intended to
have a security policy aspect at all. It is still not made explicit in
their draft.


Using the revised version of ESRV I am currently writing, a security
policy of the form 'always use TLS with any protocol at example.com
<http://example.com= >' would have the form:

example.com <http://example.com> ESRV = "tls=3Drequired"


A security policy that was specific to http would be expressed as:

example.com <= http://example.com>= ESRV "prefix=3D_http._tcp"
_http._tcp.example.com= <http://tcp.ex= ample.com> ESRV "tls=3Drequired"

or

example.com <http://example.com> ESRV = "prefix=3D*"
_http._tcp.example.com= <http://tcp.ex= ample.com> ESRV "tls=3Drequired"


The reason for this change from the -00 version is that this approach
supports CNAMEs.


The reason that I started with the requirement to use SSL is that
security policy relating to trust criteria is meaningless until you have a statement that use of SSL is required.


I have no objection to doing security policy. But I do have a real
objection to an approach that negates PKIX semantics as the TLSFP
approach does.


=A0 =A0-------- Original Message --------
=A0 =A0Subject: New Non-WG Mailing List: keyassure -- Key Assurance With D= NSSEC
=A0 =A0Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT)
=A0 =A0From: IETF Secretariat <ietf-secretariat@ietf.org
=A0 =A0<mailto:ietf-secretariat@ietf.org>>
=A0 =A0To: IETF Announcement list <ietf-announce@ietf.org
=A0 =A0<mailto:ietf-announce@ietf.org>>
=A0 =A0CC: keyassu= re@ietf.org <mailto:keyassure@ietf.org>,
=A0 =A0ondrej.sury= @nic.cz <mailto:ondrej.sury@nic.cz>, warren@kumari.net
=A0 =A0<mailto:w= arren@kumari.net>

=A0 =A0A new IETF non-working group email list has been created.

=A0 =A0List address: keyassure@ietf.org <mailto:keyassure@ietf.org>

=A0 =A0Archive:
=A0 =A0http://www.ietf.org/mail-archive/web/keyass= ure/current/maillist.html
=A0 =A0To subscribe: https://www.ietf.org/mailman/listinfo/keyassure

=A0 =A0Description: This list is for discussion relating to using
=A0 =A0DNSSEC-protected DNS queries to get greater assurance for keys and<= br> =A0 =A0certificates that are passed in existing IETF protocols. The main =A0 =A0idea is that a relying party can get additional information about a=
=A0 =A0domain name to eliminate the need for using a certificate in a
=A0 =A0protocol, to eliminate the need for sending certificates in the
=A0 =A0protocol if they are optional, and/or to assure that the certificat= e
=A0 =A0given in a protocol is associated with the domain name used by the<= br> =A0 =A0application. In all three cases, the application associates the key=
=A0 =A0or key fingerprint securely retrieved from the DNS with the domain<= br> =A0 =A0name that was used in the DNS query.

=A0 =A0For additional information, please contact the list administrators.=


=A0 =A0--
=A0 =A0 =A0Ond=F8ej Sur=FD
=A0 =A0 =A0vedouc=ED v=FDzkumu/Head of R&D department
=A0 =A0 =A0-------------------------------------------
=A0 =A0 =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC
=A0 =A0 =A0Americka 23, 120 00 Praha 2, Czech Republic
=A0 =A0 =A0mailto:= ondrej.sury@nic.cz <mailto:ondrej.sury@nic.cz> http://nic.cz/

=A0 =A0 =A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112
=A0 =A0 =A0-------------------------------------------
=A0 =A0_______________________________________________
=A0 =A0saag mailing list
=A0 =A0saag@ietf.org <mailto:saag@ietf.o= rg>

=A0 =A0https://www.ietf.org/mailman/listinfo/saag




--
Website: http://halla= mbaker.com/



--
=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.su= ry@nic.cz =A0 =A0http://ni= c.cz/
=A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112
=A0-------------------------------------------



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

--001485f626f04dd22d0491cf0cd1-- From ajs@shinkuro.com Mon Oct 4 12:17:24 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2753A6E69; Mon, 4 Oct 2010 12:17:24 -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 WQ0YR8f-TsXU; Mon, 4 Oct 2010 12:17:23 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 91FE63A6E62; Mon, 4 Oct 2010 12:17:23 -0700 (PDT) Received: from crankycanuck.ca (69-165-131-253.dsl.teksavvy.com [69.165.131.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 20C181ECB41D; Mon, 4 Oct 2010 19:18:18 +0000 (UTC) Date: Mon, 4 Oct 2010 15:18:16 -0400 From: Andrew Sullivan To: Phillip Hallam-Baker Message-ID: <20101004191816.GB379@shinkuro.com> References: <1285970705.1984.136.camel@mattlaptop2.local> <4CA7E120.6080701@extendedsubset.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) X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: Tony Finch , "dnsop@ietf.org" , keyassure@ietf.org, Marsh Ray , "saag@ietf.org" , "pkix@ietf.org" , "tls@ietf.org" Subject: Re: [saag] [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: keyassure@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 19:17:24 -0000 On Sun, Oct 03, 2010 at 11:14:23AM -0400, Phillip Hallam-Baker wrote: > What is actually being proposed is to replace the fifteen year established > system of CAs with a new scheme starting in November. [. . .] > I really don't think that we want to replace the existing infrastructure a > new PKI designed by people who claim not to understand the issues involved. > As the proposers of this scheme have done repeatedly. Suppose all of that is true (and I think it's a gross misrepresentation of the situation, but never mind that), so what? Presumably, if this new PKI sucks as much as you say it does, nobody will use it, and no harm will come. If it's a kind of snake oil that appeals to the clueless (i.e. it sucks as much as you say it does, but it's jumped up and marketed in a way that lures people who don't know any better), then it will have some spectacular failure and everyone will thenceforth avoid it. So what's the problem, even if things are as bad as you say? Also, why isn't this on the list devoted to this discussion (followup set)? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From mrex@sap.com Mon Oct 4 12:58:54 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944C83A7083; Mon, 4 Oct 2010 12:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.85 X-Spam-Level: X-Spam-Status: No, score=-9.85 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqjTg1hJd7Jc; Mon, 4 Oct 2010 12:58:53 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 69C1D3A6E7D; Mon, 4 Oct 2010 12:58:52 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o94Jxi9v021616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Oct 2010 21:59:45 +0200 (MEST) From: Martin Rex Message-Id: <201010041959.o94JxhHB019126@fs4113.wdf.sap.corp> To: stephen.farrell@cs.tcd.ie (Stephen Farrell) Date: Mon, 4 Oct 2010 21:59:43 +0200 (MEST) In-Reply-To: <4CA9FB2F.4000300@cs.tcd.ie> from "Stephen Farrell" at Oct 4, 10 05:05:03 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:38 -0700 Cc: mrex@sap.com, dnsop@ietf.org, marsh@extendedsubset.com, saag@ietf.org, pkix@ietf.org, hallam@gmail.com, tls@ietf.org Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 19:58:54 -0000 Stephen Farrell wrote: > > On 04/10/10 15:37, Martin Rex wrote: > > One thing that needs to be addressed/solved is the key/cert rollover > > for any TLS-Server, so that it is possible to list more than one > > server cert as "valid" for a Server through DNS, at least for the > > time of the transition/rollover. > > Maybe a side-issue here, but this came up in the W3C WSC work and > I wrote up an idea for that (not based on DNS) which is RFC 5697. [1] > No idea if anyone is using or would use it, though I did have a student > implement it, so it *could* work. (Note: that's an experimental-track > RFC, as it ought be:-) > > S. > > [1] http://tools.ietf.org/html/rfc5697 I do _not_ like the OtherCertificates extension. If some client would honour this for a "pinned" cert, it would allow an arbitrary CA under any of the trusted roots to completely subvert the clients motivation of pinning the cert. A sensible approach would require a certificate extension in the new cert which provides a proof from the original certificate holder (i.e. signed with the private key of the old cert), that the new cert (the public key and at least some of the certificat attributes, such as subject name, all subjectAltNames, BasicConstraints, keyUsage, ExtendedKeyUsage, maybe more) are a valid replacement for the original server cert. Key continuity without the consent of the original key holder looks dangerous to me. -Martin From hallam@gmail.com Mon Oct 4 13:09:40 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C893A705D; Mon, 4 Oct 2010 13:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.181, 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 Jq7RAQj4rgdR; Mon, 4 Oct 2010 13:09:38 -0700 (PDT) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by core3.amsl.com (Postfix) with ESMTP id EA3FE3A6E35; Mon, 4 Oct 2010 13:09:37 -0700 (PDT) Received: by wyb29 with SMTP id 29so5478558wyb.27 for ; Mon, 04 Oct 2010 13:10:33 -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=d43dvnWy80d5aja03WclzA+bJsy1oDeu4zDkctIokg8=; b=BvVEslOcGytlH0u9xKotUvhLMrd8AYv7OhslCDmej8TfUAxSHHDSMFVmvu/35gFmsE ZC3an32XaWko1JuKPSGrQJE4LV8Oge7qu0X8BvIzald6qP+yTWI5T2xQuFJjWj5+Kqdi s+W4s6A5eqHPncBVlMY2ho1YRKzHXocvLU6MU= 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=wU5jlHhrzAXJYVZJZq0whbASf0ujt/dq+IzIOB1QsoGSAb4Pso2WlGg3GPPRGxc6bk rzV9rA39J9kncSG+cCwViNjqGQuwgXIELx/MeCpF3XL+KIRktQXd3QjxWRnL2uA+bfyW Mvzu5vxj/AV0F0iidJl7fC2fmBvEOnVgZKX1k= MIME-Version: 1.0 Received: by 10.227.129.84 with SMTP id n20mr7962866wbs.61.1286222664553; Mon, 04 Oct 2010 13:04:24 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Mon, 4 Oct 2010 13:04:24 -0700 (PDT) In-Reply-To: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> Date: Mon, 4 Oct 2010 16:04:24 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016e65aeaa205d54a0491d00d91 X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 20:09:40 -0000 --0016e65aeaa205d54a0491d00d91 Content-Type: text/plain; charset=ISO-8859-1 For the past five years, CA certificates have been divided into Domain Validated and Extended Validated. As some of you know, I instigated the process that led to the creation of EV certs because I was very worried about the low quality of many DV certificates. Some DV certificates are of very low quality. Which is why I would like to see the padlock icon phased out entirely. Why does the user need to know if encryption is being used at all? Actually the reason the user need to know that encryption is being used is quite an interesting one and has to do with the lack of a security policy layer for the Internet. If we could guarantee that encryption would always be used when visiting a site where there is a certificate, there would be no need for the padlock icon. But that is a digression. The problem raised by many people here is that a site example.com can get an SSL certificate with the highest available assurance level but a MITM attack can be performed with a low assurance certificate obtained from any of the CAs listed in the browser roots. There are two possible means of attacking this problem 1) Provide a means for determining if a certificate is authorized for use 2) Sanction CAs that issue unauthorized certificates The TLSFP approach only allows the first approach to be employed. My approach, publication of the authorized CA roots permits both approaches to be employed. The way I see this working is that each CA would publish a record that customers could publish in their DNS zone to state that other CAs should not issue certs. This would have the Digest of either the root key or an intermediate cert. example.com ESRV "pkix=29823dhd2w3298yf2==" Some sites might have multiple roots advertised for cases where they are switching providers: example.com ESRV "pkix=29823dhd2w3298yf2== pkix=2u2queihwiehiuhe==" And there could also be provision for advertising CERT records and so on. We can fill in those details later. Once the necessary record is allocated, a proposal is made to CABForum to require all member CAs to verify every cert against these DNS records before issue. I believe that there should be a very high degree of voluntary compliance since it is a check that can be automated. After a short interval the mechanism is made mandatory. The browser and platform providers have the necessary tools to achieve this. They can require the checks to be specified in the annual WebTrust audit which means that every cert would have to be in compliance within a year. Non compliant certificates would be detected as a matter of course by the various companies who have reason to crawl the Web and look at SSL certs. Note that my approach does not require client implementation to be effective, but allows for client implementation if this is considered desirable and is equally effective as a means of client side enforcement. --0016e65aeaa205d54a0491d00d91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <Lots of statements concerning how CAs work>

For t= he past five years, CA certificates have been divided into Domain Validated= and Extended Validated. As some of you know, I instigated the process that= led to the creation of EV certs because I was very worried about the low q= uality of many DV certificates.


Some DV certificates are of very low qua= lity. Which is why I would like to see the padlock icon phased out entirely= . Why does the user need to know if encryption is being used at all?

Actually the reason the user need to know that encrypti= on is being used is quite an interesting one and has to do with the lack of= a security policy layer for the Internet. If we could guarantee that encry= ption would always be used when visiting a site where there is a certificat= e, there would be no need for the padlock icon.


But that is a digression. The problem ra= ised by many people here is that a site exam= ple.com can get an SSL certificate with the highest available assurance= level but a MITM attack can be performed with a low assurance certificate = obtained from any of the CAs listed in the browser roots.

There are two possible means of attacking this problem<= /div>

1) Provide a means for determining if a certificat= e is authorized for use
2) Sanction CAs that issue unauthorized c= ertificates

The TLSFP approach only allows the first approach to be= employed.

My approach, publication of the authori= zed CA roots permits both approaches to be employed.


The way I see this working is that each CA would publis= h a record that customers could publish in their DNS zone to state that oth= er CAs should not issue certs. This would have the Digest of either the roo= t key or an intermediate cert.

example.com =A0ESRV = "pkix=3D29823dhd2w3298yf2=3D=3D"

Some si= tes might have multiple roots advertised for cases where they are switching= providers:

example.com =A0ESRV = "pkix=3D29823dhd2w3298yf2=3D=3D pkix=3D2u2queihwiehiuhe=3D=3D"

And there could also be provision for advertising CE= RT records and so on. We can fill in those details later.


Once the necessary record is allocated, = a proposal is made to CABForum to require all member CAs to verify every ce= rt against these DNS records before issue. I believe that there should be a= very high degree of voluntary compliance since it is a check that can be a= utomated.

After a short interval the mechanism is made mandatory.= The browser and platform providers have the necessary tools to achieve thi= s. They can require the checks to be specified in the annual WebTrust audit= which means that every cert would have to be in compliance within a year.<= /div>

Non compliant certificates would be detected as a matte= r of course by the various companies who have reason to crawl the Web and l= ook at SSL certs.=A0


Note that my a= pproach does not require client implementation to be effective, but allows = for client implementation if this is considered desirable and is equally ef= fective as a means of client side enforcement.
--0016e65aeaa205d54a0491d00d91-- From hallam@gmail.com Mon Oct 4 13:11:47 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6D33A7016; Mon, 4 Oct 2010 13:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.181, 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 7KgFv6CDLeI7; Mon, 4 Oct 2010 13:11:46 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 274253A6E35; Mon, 4 Oct 2010 13:11:16 -0700 (PDT) Received: by wwd20 with SMTP id 20so7800wwd.1 for ; Mon, 04 Oct 2010 13:06: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; bh=d43dvnWy80d5aja03WclzA+bJsy1oDeu4zDkctIokg8=; b=BvVEslOcGytlH0u9xKotUvhLMrd8AYv7OhslCDmej8TfUAxSHHDSMFVmvu/35gFmsE ZC3an32XaWko1JuKPSGrQJE4LV8Oge7qu0X8BvIzald6qP+yTWI5T2xQuFJjWj5+Kqdi s+W4s6A5eqHPncBVlMY2ho1YRKzHXocvLU6MU= 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=wU5jlHhrzAXJYVZJZq0whbASf0ujt/dq+IzIOB1QsoGSAb4Pso2WlGg3GPPRGxc6bk rzV9rA39J9kncSG+cCwViNjqGQuwgXIELx/MeCpF3XL+KIRktQXd3QjxWRnL2uA+bfyW Mvzu5vxj/AV0F0iidJl7fC2fmBvEOnVgZKX1k= MIME-Version: 1.0 Received: by 10.227.129.84 with SMTP id n20mr7962866wbs.61.1286222664553; Mon, 04 Oct 2010 13:04:24 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Mon, 4 Oct 2010 13:04:24 -0700 (PDT) In-Reply-To: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> Date: Mon, 4 Oct 2010 16:04:24 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016e65aeaa205d54a0491d00d91 X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 20:11:47 -0000 --0016e65aeaa205d54a0491d00d91 Content-Type: text/plain; charset=ISO-8859-1 For the past five years, CA certificates have been divided into Domain Validated and Extended Validated. As some of you know, I instigated the process that led to the creation of EV certs because I was very worried about the low quality of many DV certificates. Some DV certificates are of very low quality. Which is why I would like to see the padlock icon phased out entirely. Why does the user need to know if encryption is being used at all? Actually the reason the user need to know that encryption is being used is quite an interesting one and has to do with the lack of a security policy layer for the Internet. If we could guarantee that encryption would always be used when visiting a site where there is a certificate, there would be no need for the padlock icon. But that is a digression. The problem raised by many people here is that a site example.com can get an SSL certificate with the highest available assurance level but a MITM attack can be performed with a low assurance certificate obtained from any of the CAs listed in the browser roots. There are two possible means of attacking this problem 1) Provide a means for determining if a certificate is authorized for use 2) Sanction CAs that issue unauthorized certificates The TLSFP approach only allows the first approach to be employed. My approach, publication of the authorized CA roots permits both approaches to be employed. The way I see this working is that each CA would publish a record that customers could publish in their DNS zone to state that other CAs should not issue certs. This would have the Digest of either the root key or an intermediate cert. example.com ESRV "pkix=29823dhd2w3298yf2==" Some sites might have multiple roots advertised for cases where they are switching providers: example.com ESRV "pkix=29823dhd2w3298yf2== pkix=2u2queihwiehiuhe==" And there could also be provision for advertising CERT records and so on. We can fill in those details later. Once the necessary record is allocated, a proposal is made to CABForum to require all member CAs to verify every cert against these DNS records before issue. I believe that there should be a very high degree of voluntary compliance since it is a check that can be automated. After a short interval the mechanism is made mandatory. The browser and platform providers have the necessary tools to achieve this. They can require the checks to be specified in the annual WebTrust audit which means that every cert would have to be in compliance within a year. Non compliant certificates would be detected as a matter of course by the various companies who have reason to crawl the Web and look at SSL certs. Note that my approach does not require client implementation to be effective, but allows for client implementation if this is considered desirable and is equally effective as a means of client side enforcement. --0016e65aeaa205d54a0491d00d91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <Lots of statements concerning how CAs work>

For t= he past five years, CA certificates have been divided into Domain Validated= and Extended Validated. As some of you know, I instigated the process that= led to the creation of EV certs because I was very worried about the low q= uality of many DV certificates.


Some DV certificates are of very low qua= lity. Which is why I would like to see the padlock icon phased out entirely= . Why does the user need to know if encryption is being used at all?

Actually the reason the user need to know that encrypti= on is being used is quite an interesting one and has to do with the lack of= a security policy layer for the Internet. If we could guarantee that encry= ption would always be used when visiting a site where there is a certificat= e, there would be no need for the padlock icon.


But that is a digression. The problem ra= ised by many people here is that a site exam= ple.com can get an SSL certificate with the highest available assurance= level but a MITM attack can be performed with a low assurance certificate = obtained from any of the CAs listed in the browser roots.

There are two possible means of attacking this problem<= /div>

1) Provide a means for determining if a certificat= e is authorized for use
2) Sanction CAs that issue unauthorized c= ertificates

The TLSFP approach only allows the first approach to be= employed.

My approach, publication of the authori= zed CA roots permits both approaches to be employed.


The way I see this working is that each CA would publis= h a record that customers could publish in their DNS zone to state that oth= er CAs should not issue certs. This would have the Digest of either the roo= t key or an intermediate cert.

example.com =A0ESRV = "pkix=3D29823dhd2w3298yf2=3D=3D"

Some si= tes might have multiple roots advertised for cases where they are switching= providers:

example.com =A0ESRV = "pkix=3D29823dhd2w3298yf2=3D=3D pkix=3D2u2queihwiehiuhe=3D=3D"

And there could also be provision for advertising CE= RT records and so on. We can fill in those details later.


Once the necessary record is allocated, = a proposal is made to CABForum to require all member CAs to verify every ce= rt against these DNS records before issue. I believe that there should be a= very high degree of voluntary compliance since it is a check that can be a= utomated.

After a short interval the mechanism is made mandatory.= The browser and platform providers have the necessary tools to achieve thi= s. They can require the checks to be specified in the annual WebTrust audit= which means that every cert would have to be in compliance within a year.<= /div>

Non compliant certificates would be detected as a matte= r of course by the various companies who have reason to crawl the Web and l= ook at SSL certs.=A0


Note that my a= pproach does not require client implementation to be effective, but allows = for client implementation if this is considered desirable and is equally ef= fective as a means of client side enforcement.
--0016e65aeaa205d54a0491d00d91-- From jwkckid1@ix.netcom.com Mon Oct 4 14:14:27 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241E33A70C3; Mon, 4 Oct 2010 14:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=0.953, 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 bR-3S5CzXLup; Mon, 4 Oct 2010 14:14:24 -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 0F1423A70BB; Mon, 4 Oct 2010 14:14:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=bPsxfn/51kXJnyXpm9oYgoxEnZyG/LCnvPF48iGnYvYniNmDiRZuF9Htg51naYuM; 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.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1P2sNT-0000IG-UP; Mon, 04 Oct 2010 17:15:19 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 4 Oct 2010 17:15:19 -0400 Message-ID: <23479345.1286226919917.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Mon, 4 Oct 2010 16:15:19 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Michael StJohns , pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@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: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688d304796be347e02cac8c2b5d708faa58350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 21:14:27 -0000 Michael and all, Nice outline. What still bothers me is all this is still tied to trust anchors. How do we or anyone know or do about a trust anchor that has been corrupted or otherwise breached? It is likely that the knowing of same will be delayed by some time factor and the potential damage assessment may take even longer. So there is a real likelihood of potential harm here... Secondly, the same condition could/will apply to CA's Cert Database with similar results. As some of us already know and has been detected, reported and documented a few of the larger and well known CA's have had their Cert databases breached leaving Cert holders from those CA's in a very uncomfortable if not dangerous position on a number of levels. -----Original Message----- >From: Michael StJohns >Sent: Oct 4, 2010 1:30 PM >To: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org >Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org >Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC > >Hi - > >DNSSEC seems to be picking on PKIX and vice versa - maybe the right answer is both? > > >DNSSEC provides a "secure" association FROM the name TO the IP address. But the DNS domain owner tends not to be the host owner so this asserted association may not reflect the intent of the host owner. Also, DNSSEC doesn't protect from IP hijacking (re-routing). > >PKIX provides a "secure" association TO/FROM "a" name to a public key. The host owner holds the private key and can prove "ownership" of the related public key. But the host owner tends not to be the domain owner so the asserted association may not reflect the intent of the DNS domain owner. > > >What if - the PKIX certificate for the host contained a "permit" for the name signed by the DNS owner? A signature over the hash of the public key in the certificate, and the DNS name - and maybe some expiration info verifiable by the data in DNSSEC? > > >The path goes something like: > >1) Use DNS and DNSSEC to find the host (or even just DNS) >2) Use TLS to grab the certificate >3) Verify the certificate using the PKIX path to a trust anchor >4) Verify the host knows the private key related to the host certificate >5) Verify the extension in the certificate was signed by the domain's DNSSEC key (pick one of special key, KSK or ZSK) >6) Verify the name offered in the certificate matches the DNS name looked up. > >You've verified that: >a) The zone owner has assigned the name to the owner of the cert's private key >b) The host owner has agreed the host has the DNS name. >c) The IP to Name mapping (what might be in the PTR record and signed under DNSSEC - maybe). > >The DNSSEC name to IP address mapping becomes irrelevant for trust purposes which means that IP hijacking is no longer an issue. > >A random PKIX forming a certificate with a DNS name in it can't form one that proves the name assignment from the DNS, so the large set of PKIX trust anchors becomes less of an issue. > >Mike > > > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls 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 From mrex@sap.com Mon Oct 4 17:45:20 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8235C3A6D27; Mon, 4 Oct 2010 17:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.858 X-Spam-Level: X-Spam-Status: No, score=-9.858 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uSitcw2WQWp; Mon, 4 Oct 2010 17:45:19 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 081F93A6C73; Mon, 4 Oct 2010 17:45:18 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o950kCXZ011877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Oct 2010 02:46:12 +0200 (MEST) From: Martin Rex Message-Id: <201010050046.o950kBPe005266@fs4113.wdf.sap.corp> To: mstjohns@comcast.net (Michael StJohns) Date: Tue, 5 Oct 2010 02:46:11 +0200 (MEST) In-Reply-To: <20101004182935.97CE53A705B@core3.amsl.com> from "Michael StJohns" at Oct 4, 10 02:30:29 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 00:45:20 -0000 Michael StJohns wrote: > > DNSSEC seems to be picking on PKIX and vice versa > - maybe the right answer is both? In theory, PKIX could provide real value. In practice, the PKIX abuse commonly described as "TLS PKI" that performs a non-popup server endpoint identification with the help of target DNS hostnames has infinitesimal close to zero value over DNSSEC. Conceptually, limiting the certificates that can be used to provide servers on specific DNS hostnames to certificates explicitly listed by the DNS admin would significantly reduce the huge attack surface of the existing "TLS PKI" with >100 independent pre-configured trust-anchors in most TLS client software. > > DNSSEC provides a "secure" association FROM the name TO the IP address. > But the DNS domain owner tends not to be the host owner so this asserted > association may not reflect the intent of the host owner. > Also, DNSSEC doesn't protect from IP hijacking (re-routing). Incorrect characterisation. DNSSEC provides only for secure distribution of DNS records. Whether the distributed DNS records are accurate or trustworthy is a completely distinct issue. > > PKIX provides a "secure" association TO/FROM "a" name to a public key. This "secure" association is limited to specific "vetted" attributes (which may or may not be described in a legalese Certificate Practice Statement (CPS)), with one notable and serious exception: Any occurrence of a DNS hostname in a PKIX cert is based entirely and completely on the DNS delegation records, and all of the popular non-prompting server endpoint identification completely ignores all carefully reviewed cert attributes and relies _completely_ on the DNS hostnames based on the DNS delegation records. > > The host owner holds the private key and can prove "ownership" of the > related public key. But the host owner tends not to be the domain > owner so the asserted association may not reflect the intent of the > DNS domain owner. While this may be true in practice, the domain owner is a person that is definitely entitled to get certs issued for hostnames in his domain from most (probably all) "TLS PKI CAs" and the domain owner is also the one that can create and is entitled to distribute arbitrary DNS records in his DNS domain through DNS and DNSSEC protocols. Authentication that should reliably exclude the DNS admin for a servers DNS hostname from acquiring a "valid" server cert, will need to completely ban the DNS hostname from the server endpoint identification. One means to do this would be to securly authenticate the server by his public key, also called "certificate pinning", also mentioned here http://www.w3.org/TR/wsc-ui/#selfsignedcerts Selective trust and trust being affected by repeated encounter is evolutionary heritage and intrinsic to every mammal and most human beings. Unfortunately, some TLS-clients make it increasingly difficult to practice such evolutionary proven approaches to server endpoint identification. -Martin From hallam@gmail.com Tue Oct 5 06:21:33 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B293A6F51 for ; Tue, 5 Oct 2010 06:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.468 X-Spam-Level: X-Spam-Status: No, score=-0.468 tagged_above=-999 required=5 tests=[AWL=-1.769, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 uLwFYBM7RwKY for ; Tue, 5 Oct 2010 06:21:32 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0FA793A6C24 for ; Tue, 5 Oct 2010 06:21:31 -0700 (PDT) Received: by wwj40 with SMTP id 40so4018835wwj.13 for ; Tue, 05 Oct 2010 06:22: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=xl+8vQHYfZ1Fo3UhIZJXPkrEncCy0yQqAXWwHvsW2hs=; b=Z7Xts+E5c1BdXCRSSzv8auUZ/h6RTzn0FePBeAHh8gk2MTYrcytT3N8/YCMSFAqJAM HSqlVteM7LWg8ka9LjMv5r2gUy/zG5Wg/Xuc+N9Li7PpibEevTzNVxkEq4zdBRfQrdA3 gyi6/RgNmyno8W+V26B4hwjO/nZchrlGOd2cY= 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=wjAdDUAyvdw7wvti/rH3tbFN1P/08MWwZPIPzJ3ygc2TFu1o2jJ6fKFD69s/qgUm/W jyIVHornJaMLFlvvR3h3+w8WTTCKSYBZCmW66pNUGkZucUSWmDxLlEVehBjI6tClUscP Ia/NKYkA0DD4tZdzTO6cVPIRd8dT37TuT7qCU= MIME-Version: 1.0 Received: by 10.216.65.204 with SMTP id f54mr1064460wed.3.1286284948926; Tue, 05 Oct 2010 06:22:28 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Tue, 5 Oct 2010 06:22:28 -0700 (PDT) In-Reply-To: References: <092405dc28038119878c75f1b01f29bc.squirrel@www.trepanning.net> Date: Tue, 5 Oct 2010 09:22:28 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=000e0ce0b8c675f0b10491de8da7 X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 13:21:33 -0000 --000e0ce0b8c675f0b10491de8da7 Content-Type: text/plain; charset=ISO-8859-1 AES and SHA-2 are part of Suite B and more or less everyone uses them. Plenty of people require stronger crypto than 128 bit. While 128 bit work-factor is more than ample if you believe that the algorithms are sound, the 256 bit variants offer more rounds and more rounds means a stronger scheme. If you are encrypting medical data that is required to be confidential for the lifetime of a 6 month old patient, you might well be obliged to use 256 bit. These issues tend not to affect IETF much because most of what we do is communications protocols and the sensitivity of the traffic is mostly limited to a few months. Knowing the internals of a $1 billion merger deal would be very valuable to an attacker before the announcement but worthless afterwards. But on the standards issue, I have for many years thought that we should have an RFC that lists the set of base crypto that compliant applications MUST support and MUST deprecate. So then an S/MIME implementation would advertise itself as compliant with RFC5751and RFC6666 and this would mean that it supported all the crypto suites in the MUST implement list and does not generate content in the MUST deprecate list in the 'normal' mode of use. The reason I have not gone further with this proposal is that it really requires a policy layer in the Internet stack before it is useful. On Mon, Oct 4, 2010 at 11:41 PM, Peter Gutmann wrote: > "Dan Harkins" writes: > > >That's an odd statement. There is suite B guidance for use of quite alot > of > >IETF protocols-- TLS, SSH, IKE/IPsec, S/MIME > > And how many of those have you see used outside the USG, which operates > more > or less in its own world anyway? > > Peter. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Website: http://hallambaker.com/ --000e0ce0b8c675f0b10491de8da7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AES and SHA-2 are part of Suite B and more or less everyone uses them.
=
Plenty of people require stronger crypto than 128 bit. While= 128 bit work-factor is more than ample if you believe that the algorithms = are sound, the 256 bit variants offer more rounds and more rounds means a s= tronger scheme.

If you are encrypting medical data that is required to be co= nfidential for the lifetime of a 6 month old patient, you might well be obl= iged to use 256 bit.


These issues t= end not to affect IETF much because most of what we do is communications pr= otocols and the sensitivity of the traffic is mostly limited to a few month= s. Knowing the internals of a $1 billion merger deal would be very valuable= to an attacker before the announcement but worthless afterwards.


But on the standards issue, I have for m= any years thought that we should have an RFC that lists the set of base cry= pto that compliant applications MUST support and MUST deprecate.

So then an S/MIME implementation would advertise itself as c= ompliant with RFC5751and RFC6666 and this would mean that it supported all = the crypto suites in the MUST implement list and does not generate content = in the MUST deprecate list in the 'normal' mode of use.


The reason I have not gone further with = this proposal is that it really requires a policy layer in the Internet sta= ck before it is useful.


On Mon, Oct 4, 2010 at 11:41 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
"Dan Harkins" <dharkins@lounge.org> writes:

>That's an odd statement. There is suite B guidance for use of quite= alot of
>IETF protocols-- TLS, SSH, IKE/IPsec, S/MIME

And how many of those have you see used outside the USG, which operat= es more
or less in its own world anyway?

Peter.

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



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

--000e0ce0b8c675f0b10491de8da7-- From DPKemp@missi.ncsc.mil Tue Oct 5 09:32:50 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CF23A6FA4; Tue, 5 Oct 2010 09:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=1.017, 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 VJbVxG1g+42q; Tue, 5 Oct 2010 09:32:47 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id AD6773A6FC8; Tue, 5 Oct 2010 09:32:47 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id o95GXfBt000479; Tue, 5 Oct 2010 12:33:41 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Oct 2010 12:32:21 -0400 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: Tue, 5 Oct 2010 12:32:59 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC Thread-Index: Actj8IMQKtYXwe1DQHq0gJKQySimfAAshQ7Q References: <1285970705.1984.136.camel@mattlaptop2.local> From: "Kemp, David P." To: "Ben Laurie" , "Phillip Hallam-Baker" X-OriginalArrivalTime: 05 Oct 2010 16:32:21.0859 (UTC) FILETIME=[E2916B30:01CB64AA] X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:38 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 16:32:50 -0000 You are confusing attack surface with vulnerability. Without getting into technology specifics, if A .and. B must be successfully attacked in order to cause a problem, then having two systems can only reduce the vulnerability even though there are more places to attack. If the problem is availability, then the best strategy is redundancy - use multiple sources for a single information item. If the problem is integrity, the best strategy is diversity - use different sources for different information items. If either source gives the wrong answer you fail, but fail safely. (Redundancy and diversity can be combined of course, but then combining rules such voting thresholds have to be specified).=20 For the DNS/PKI case, if A is an IP address for a dnsname and B is a public key for a dnsname, then it is necessary to attack the sources of A and B in order to successfully spoof a named server. If A and B come from the same system (e.g., DNS) it is necessary to attack only that system. If they come from different systems (DNS and PKI) then it is necessary to attack both. Attacking only one may cause an availability failure, but not an integrity failure. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ben Laurie If I deploy the DNS solution, stating that DNS is authoritative, then my attack surface now excludes all CAs. How is that an increase in attack surface? Contrast with today's situation, where my attack surface is increased on a regular basis by the introduction of new CAs, without any consultation with me at all. From hallam@gmail.com Tue Oct 5 09:55:54 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6D653A6EE7; Tue, 5 Oct 2010 09:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.207, 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 tqB7+Ti84XEc; Tue, 5 Oct 2010 09:55:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6EF793A6CE1; Tue, 5 Oct 2010 09:55:52 -0700 (PDT) Received: by wyi11 with SMTP id 11so7276403wyi.31 for ; Tue, 05 Oct 2010 09:56:50 -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=qeACtmJpx0u9kcCTLV3iZjdvxy0T8R7wFirbWu1+KL8=; b=NruY3oASaX3h8schAzzn0BWcCQlZfMN7RJdXWxxEiJlRKKI2RIW03MQkfJKcVFEAvZ eyqNBxkgAAx2HYPsRquKrNQr5qQocVoVff+u0cR1pSM0nDav8dmWkIlvVH72tQLSGT5P tR0bB3s8p0jHDyjwoloafLtbzcSRaaUEG0IvI= 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=kvYMQAACMkcQdRT34B7BBMtTJemOf+JNB2EYyPxJnvhRMgoB6egk2Mywn+PpxLGdFr A6tvEOkoLSXyxURp7gtvq4YqWX9buDKiiNgNeC9iye64jlubvZTXo7DHyx4MqetPc9MQ TVIjSreHwza/0peiXrmUrHx6vuAeNaBOq6GY0= MIME-Version: 1.0 Received: by 10.216.1.6 with SMTP id 6mr9510457wec.24.1286297809910; Tue, 05 Oct 2010 09:56:49 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Tue, 5 Oct 2010 09:56:49 -0700 (PDT) In-Reply-To: References: <1285970705.1984.136.camel@mattlaptop2.local> Date: Tue, 5 Oct 2010 12:56:49 -0400 Message-ID: From: Phillip Hallam-Baker To: "Kemp, David P." Content-Type: multipart/alternative; boundary=0016364d29bf08fb170491e18c77 X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 16:55:55 -0000 --0016364d29bf08fb170491e18c77 Content-Type: text/plain; charset=ISO-8859-1 David, When I originally looked at this scheme I thought that it was intended to reduce the attack surface in the manner you describe. Clearly if you have two controls, A and B and BOTH must be compromised, the system is less likely to be compromised than either A or B. But the design approach taken in the Hoffman et. al. proposal is that publication of a DNSSEC assurance for a cert disables verification on the PKIX chain unless the 'preferences' flag is set. This flag will be buried in a base64 encoded sub-field encoding. In practice only a proportion of clients will deploy this mechanism. So if A is PKIX and B is DNSSEC, it will be possible for an attacker to succeed if either A or B is compromised in one configuration and if either A or A and B is compromised in the other. People seem to be confusing the security of the cryptographic protocols with the security of the infrastructures that support them. The weakest link in any competently designed security scheme is people and processes. The PKIX infrastructure has been operating as a security infrastructure for 15 years, its flaws are reasonably well understood at this point. DNS on the other hand is a non-security infrastructure that people appear to want to immediately co-opt to duplicate functions of PKIX. "What could possibly go wrong" Given that the problem that instigated this proposal is mis-issue of a certificate. It would appear to me that we should look at deploying controls that reduce the probability of mis-issue of a certificate before we rush to deploy a completely new validation scheme for certificates in the six month timescale being proposed in this charter. In particular, it would be rather useful to have controls of the form: * Certificates only valid if issued into a certificate chain with specified properties * Obtain additional authentication according to protocol X and key Y. On Tue, Oct 5, 2010 at 12:32 PM, Kemp, David P. wrote: > You are confusing attack surface with vulnerability. Without getting > into technology specifics, if A .and. B must be successfully attacked in > order to cause a problem, then having two systems can only reduce the > vulnerability even though there are more places to attack. > > If the problem is availability, then the best strategy is redundancy - > use multiple sources for a single information item. If the problem is > integrity, the best strategy is diversity - use different sources for > different information items. If either source gives the wrong answer > you fail, but fail safely. (Redundancy and diversity can be combined of > course, but then combining rules such voting thresholds have to be > specified). > > For the DNS/PKI case, if A is an IP address for a dnsname and B is a > public key for a dnsname, then it is necessary to attack the sources of > A and B in order to successfully spoof a named server. If A and B come > from the same system (e.g., DNS) it is necessary to attack only that > system. If they come from different systems (DNS and PKI) then it is > necessary to attack both. Attacking only one may cause an availability > failure, but not an integrity failure. > > Dave > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Ben Laurie > > > If I deploy the DNS solution, stating that DNS is authoritative, then > my attack surface now excludes all CAs. How is that an increase in > attack surface? > > Contrast with today's situation, where my attack surface is increased > on a regular basis by the introduction of new CAs, without any > consultation with me at all. > > -- Website: http://hallambaker.com/ --0016364d29bf08fb170491e18c77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David,

When I originally looked at this scheme I thought= that it was intended to reduce the attack surface in the manner you descri= be.

Clearly if you have two controls, A and B and = BOTH must be compromised, the system is less likely to be compromised than = either A or B.

But the design approach taken in the Hoffman et. al. pr= oposal is that publication of a DNSSEC assurance for a cert disables verifi= cation on the PKIX chain unless the 'preferences' flag is set. This= flag will be buried in a base64 encoded sub-field encoding.

In practice only a proportion of clients will deploy th= is mechanism. So if A is PKIX and B is DNSSEC, it will be possible for an a= ttacker to succeed if either A or B is compromised in one configuration and= if either A or A and B is compromised in the other.


People seem to be confusing the security= of the cryptographic protocols with the security of the infrastructures th= at support them. The weakest link in any competently designed security sche= me is people and processes. The PKIX infrastructure has been operating as a= security infrastructure for 15 years, its flaws are reasonably well unders= tood at this point. DNS on the other hand is a non-security infrastructure = that people appear to want to immediately co-opt to duplicate functions of = PKIX.

"What could possibly go wrong"

=
Given that the problem that instigated this proposal is mis-= issue of a certificate. It would appear to me that we should look at deploy= ing controls that reduce the probability of mis-issue of a certificate befo= re we rush to deploy a completely new validation scheme for certificates in= the six month timescale being proposed in this charter.

In particular, it would be rather useful to have contro= ls of the form:

* Certificates only valid if issue= d into a certificate chain with specified properties
* Obtain add= itional authentication according to protocol X and key Y.



On Tue, O= ct 5, 2010 at 12:32 PM, Kemp, David P. <DPKemp@missi.ncsc.mil> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;"> You are confusing attack surface with vulnerability. =A0Without getting
into technology specifics, if A .and. B must be successfully attacked in order to cause a problem, then having two systems can only reduce the
vulnerability even though there are more places to attack.

If the problem is availability, then the best strategy is redundancy -
use multiple sources for a single information item. =A0If the problem is integrity, the best strategy is diversity - use different sources for
different information items. =A0If either source gives the wrong answer
you fail, but fail safely. =A0(Redundancy and diversity can be combined of<= br> course, but then combining rules such voting thresholds have to be
specified).

For the DNS/PKI case, if A is an IP address for a dnsname and B is a
public key for a dnsname, then it is necessary to attack the sources of
A and B in order to successfully spoof a named server. =A0If A and B come from the same system (e.g., DNS) it is necessary to attack only that
system. =A0If they come from different systems (DNS and PKI) then it is
necessary to attack both. =A0Attacking only one may cause an availability failure, but not an integrity failure.

Dave


-----Original Message-----
From: pkix-bounces@ietf.org [m= ailto:pkix-bounces@ietf.org] O= n Behalf Of
Ben Laurie


If I deploy the DNS solution, stating that DNS is authoritative, then
my attack surface now excludes all CAs. How is that an increase in
attack surface?

Contrast with today's situation, where my attack surface is increased on a regular basis by the introduction of new CAs, without any
consultation with me at all.




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

--0016364d29bf08fb170491e18c77-- From CWallace@cygnacom.com Tue Oct 5 10:00:32 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8410B3A6FC8; Tue, 5 Oct 2010 10:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, 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 8QGFCJRWbsNw; Tue, 5 Oct 2010 10:00:31 -0700 (PDT) Received: from mail152.messagelabs.com (mail152.messagelabs.com [216.82.253.19]) by core3.amsl.com (Postfix) with SMTP id 94C513A6FCB; Tue, 5 Oct 2010 10:00:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-4.tower-152.messagelabs.com!1286298088!40474744!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.8] Received: (qmail 12974 invoked from network); 5 Oct 2010 17:01:29 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-4.tower-152.messagelabs.com with SMTP; 5 Oct 2010 17:01:29 -0000 x-cr-hashedpuzzle: ATtY HlAI Inln Tonn XyTy Z66D ksGn mi6F r+RU tFya u7MP xCt+ xmYw 4PT8 AAyZqg== ACJthw==; 7; YgBlAG4AbABAAGcAbwBvAGcAbABlAC4AYwBvAG0AOwBkAG4AcwBvAHAAQABpAGUAdABmAC4AbwByAGcAOwBkAHAAawBlAG0AcABAAG0AaQBzAHMAaQAuAG4AYwBzAGMALgBtAGkAbAA7AG8AbgBkAHIAZQBqAC4AcwB1AHIAeQBAAG4AaQBjAC4AYwB6ADsAcABrAGkAeABAAGkAZQB0AGYALgBvAHIAZwA7AHMAYQBhAGcAQABpAGUAdABmAC4AbwByAGcAOwB0AGwAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {0274E4A0-AA9F-4243-B1A3-3F92433839EE}; YwB3AGEAbABsAGEAYwBlAEAAYwB5AGcAbgBhAGMAbwBtAC4AYwBvAG0A; Tue, 05 Oct 2010 17:01:16 GMT; UgBFADoAIABbAHAAawBpAHgAXQAgAFsAVABMAFMAXQAgACAAQwBlAHIAdAAgAEUAbgB1AG0AZQByAGEAdABpAG8AbgAgAGEAbgBkACAASwBlAHkAIABBAHMAcwB1AHIAYQBuAGMAZQAgAFcAaQB0AGgAIABEAE4AUwBTAEUAQwA= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 5 Oct 2010 13:01:16 -0400 Message-ID: In-Reply-To: <60283F04-0795-46E9-AE42-58EA099A9BF5@nic.cz> x-cr-puzzleid: {0274E4A0-AA9F-4243-B1A3-3F92433839EE} X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC Thread-Index: ActkrgmyDFOIv2qpQ2yCMhykxDeLbgAAA5Kg References: <1285970705.1984.136.camel@mattlaptop2.local> <60283F04-0795-46E9-AE42-58EA099A9BF5@nic.cz> From: "Carl Wallace" To: =?iso-8859-2?B?T25k+GVqIFN1cv0=?= , "Kemp, David P." X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:00:32 -0000 > You are working on wrong assumptions. The DV certs are exactly as > strong as your DNS is. You only need to attack DNS to issue a DV cert. >=20 > Ondrej Sury Certificate issuance is not the end of the game. Clients have = opportunity to avoid being fooled by a DV certificate if they choose. = Why disarm the client? =20 From schoen@eff.org Tue Oct 5 11:03:27 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C7A3A7079; Tue, 5 Oct 2010 11:03:27 -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 8YOWogiFFpbW; Tue, 5 Oct 2010 11:03:26 -0700 (PDT) Received: from mail1.eff.org (mail1.eff.org [64.147.188.4]) by core3.amsl.com (Postfix) with ESMTP id C456A3A6FB7; Tue, 5 Oct 2010 11:03:25 -0700 (PDT) Received: from sescenties (localhost [127.0.0.1]) by mail1.eff.org (Postfix) with ESMTP id AC038BE099; Tue, 5 Oct 2010 11:04:25 -0700 (PDT) Date: Tue, 5 Oct 2010 11:04:23 -0700 From: Seth David Schoen To: "Kemp, David P." Message-ID: <20101005180422.GA15277@sescenties> References: <1285970705.1984.136.camel@mattlaptop2.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: dnsop@ietf.org, saag@ietf.org, pkix@ietf.org, Phillip Hallam-Baker , tls@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 18:03:27 -0000 Kemp, David P. writes: > For the DNS/PKI case, if A is an IP address for a dnsname and B is a > public key for a dnsname, then it is necessary to attack the sources of > A and B in order to successfully spoof a named server. If A and B come > from the same system (e.g., DNS) it is necessary to attack only that > system. If they come from different systems (DNS and PKI) then it is > necessary to attack both. Attacking only one may cause an availability > failure, but not an integrity failure. In the case where an attacker controls the network, they can win with B only, without A, because they can perform an active attack even when the client knows the correct IP address for the server. Consider http://www.ex-parrot.com/~pete/upside-down-ternet.html which only attempts to attack HTTP without TLS. But notice that it would work correctly even with DNSSEC because it does not rely on misleading the client about the server's IP address. In this threat model, attacking the source of A is not necessary for spoofing a TLS-enabled server, but attacking the source of B is. This threat model could apply realistically to many public networks, particularly because the attacker need not be the network's legitimate owner in order to control the network (for instance, through compromised routers, DHCP spoofing, or ARP spoofing). In this model, getting the service's correct public key to the client is necessary and sufficient all by itself. From marsh@extendedsubset.com Tue Oct 5 11:36:01 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BFF3A6FC2; Tue, 5 Oct 2010 11:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnxI5AMZl1Si; Tue, 5 Oct 2010 11:36:00 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id ED26A3A7097; Tue, 5 Oct 2010 11:35:59 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1P3CNl-0005Km-Nc; Tue, 05 Oct 2010 18:36:57 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7086D6018; Tue, 5 Oct 2010 18:36:56 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+8ypa8RMu5rlKDWfvP1mXa36zdcsNGry8= Message-ID: <4CAB7048.6090603@extendedsubset.com> Date: Tue, 05 Oct 2010 13:36:56 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <1285970705.1984.136.camel@mattlaptop2.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: "Kemp, David P." , dnsop@ietf.org, keyassure@ietf.org, tls@ietf.org, pkix@ietf.org, saag@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 18:36:01 -0000 On 10/05/2010 11:56 AM, Phillip Hallam-Baker wrote: > > Clearly if you have two controls, A and B and BOTH must be compromised, > the system is less likely to be compromised than either A or B. > > But the design approach taken in the Hoffman et. al. proposal is that > publication of a DNSSEC assurance for a cert disables verification on > the PKIX chain unless the 'preferences' flag is set. This flag will be > buried in a base64 encoded sub-field encoding. > > In practice only a proportion of clients will deploy this mechanism. So > if A is PKIX and B is DNSSEC, it will be possible for an attacker to > succeed if either A or B is compromised in one configuration and if > either A or A and B is compromised in the other. +1 In practice, only a proportion of servers will deploy this mechanism until such time as Firefox and Chrome are willing to shut them off. I've read that because DNSSEC records are large, some resolvers cannot pass them on. Testing a few months ago indicated that it worked on something like 4 out of 5 internet connections I tried it on. But it's quite possible that there are little wifi-router-firewall boxes in millions of homes that don't expect such large packets on port 53. So clients will have to continue to operate in the absence of DNSSEC information for the forseeable future. It's also reasonable to suspect that an attacker (who in our analysis is already presumed to have a fraudulent server cert and the ability to make use of it, i.e., MitM) would also be able to downgrade DNS to strip out this "preferences" flag (if some intermediate box isn't doing it already). Therefore the attacker may be able to choose to attack the via a DNSSEC problem (e.g., a website vuln at the site's DNS registrar) or via PKI (e.g., a rouge sub-CA). So the attack surface is, in fact, increased. Unless I'm missing something about how DNSSEC prevents downgrade attacks, which is quite possible. > People seem to be confusing the security of the cryptographic protocols > with the security of the infrastructures that support them. The weakest > link in any competently designed security scheme is people and > processes. Perhaps only because security designers have successfully washed their hands of the harder part of the problem? > The PKIX infrastructure has been operating as a security > infrastructure for 15 years, its flaws are reasonably well understood at > this point. That's a very nice way of saying it. I would have said it this way: IT SUCKS!!!! The fact that the national telephone company of Qwertystan can delegate a sub-CA that can delegate a sub-CA that can issue a certificate which enables the MitM of the connection between my notebook and my company's VPN server is a scandal. If anyone had ever proposed such a scheme to people who weren't already steeped in the status quo, they'd be laughed out of their industry. > DNS on the other hand is a non-security infrastructure that > people appear to want to immediately co-opt to duplicate functions of PKIX. Rather than wanting to co-opt or duplicate the current PKI scheme, it may be that people are simply eager to rid themselves of it. Not saying it's perfect, I honestly haven't looked into it very deeply, but DNSSEC holds a lot of promise: 1. It builds on top of DNS, which is reasonably mature. 2. It was designed for actual security with knowledge of modern attacks and the benefit of hindsight. 3. It was designed at all, rather than simply evolving to enable various sets of business deals. 4. It roots to one entity is ostensibly neutral and non-profit. They have a track record which can be evaluated. They largely own DNS anyway. 5. Domain holders already understand the need to handle their domain name registrations as super-critical assets. 6. It appears to delegate more control to the domain holder to define and authenticate his own data. He doesn't have to deal with weird "per server licensing" (whatever that means) agreements. 7. It appears to reduce or eliminate some recurring fees associated with server authentication. Of course, this list leaves out anything bad about it. Possibly, it's worse on balance. > "What could possibly go wrong" Lots, particularly during the transition period when parallel systems must be trusted. Which is why such a proposal needs a lot of thinking and real-world testing. Which is why it would have been better for it to have been proposed earlier. > Given that the problem that instigated this proposal is mis-issue of a > certificate. It would appear to me that we should look at deploying > controls that reduce the probability of mis-issue of a certificate It's not a question of probability, it's the option of the attacker. If you have something worth protecting, you need to be defending against a targeted attack. The attacker may or may not have the capability to obtain a usable private key, but if he can, he can be expected to use it. So it's not a question of "probability if" but of "who", i.e., who are the attackers I wish to defend against. There are may of users of the technology who do not desire to trust (or actively mistrust) many of the entities controlling CAs. > before we rush to deploy a completely new validation scheme for > certificates in the six month timescale being proposed in this charter. > > In particular, it would be rather useful to have controls of the form: > > * Certificates only valid if issued into a certificate chain with > specified properties > * Obtain additional authentication according to protocol X and key Y. Anything limiting the number and scope of CAs would be an improvement. But such improvements could have been implemented at any time previously, yet they were not. Maybe the prospect of DNSSEC replacing it will provide motivation for PKI to improve. But by then the train may already be rolling. - Marsh From mrex@sap.com Tue Oct 5 12:46:03 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A923A6E62; Tue, 5 Oct 2010 12:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.866 X-Spam-Level: X-Spam-Status: No, score=-9.866 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xDHy26W5LDr; Tue, 5 Oct 2010 12:46:01 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 698EC3A6DF6; Tue, 5 Oct 2010 12:46:00 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o95JkuHP024701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Oct 2010 21:46:57 +0200 (MEST) From: Martin Rex Message-Id: <201010051946.o95JkteM009316@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Tue, 5 Oct 2010 21:46:55 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Oct 5, 10 12:56:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: pkix@ietf.org, DPKemp@missi.ncsc.mil, dnsop@ietf.org, tls@ietf.org, saag@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 19:46:04 -0000 Phillip Hallam-Baker wrote: > > David P. Kemp wrote: > > > > For the DNS/PKI case, if A is an IP address for a dnsname and B is a > > public key for a dnsname, then it is necessary to attack the sources of > > A and B in order to successfully spoof a named server. If A and B come > > from the same system (e.g., DNS) it is necessary to attack only that > > system. If they come from different systems (DNS and PKI) then it is > > necessary to attack both. Attacking only one may cause an availability > > failure, but not an integrity failure. > > When I originally looked at this scheme I thought that it was intended to > reduce the attack surface in the manner you describe. > > Clearly if you have two controls, A and B and BOTH must be compromised, the > system is less likely to be compromised than either A or B. The DNS admin that controls A can always get a perfectly valid certificate B issued and successfully impersonate all services offered on servers in his DNS domain. Because of this characteristic of the TLS PKI, it doesn't matter how much scrutiny the CAs apply, if you can not trust the DNS admin, you loose. Requiring the involvement of a pre-trusted commercial CA makes it less attractive to DNS admins to abuse their position and harder for attackers that manage to modify DNS records of DNSSEC signed zones to impersonate servers in that DNS zone. Obtaining CA-signed server certs may require "official procurement", so the issuance of the server certs goes on record at the issuing CA and the domain owners procurement. This could serve as a deterrent for outsourced DNS services or unhappy DNS admins. > > But the design approach taken in the Hoffman et. al. proposal is that > publication of a DNSSEC assurance for a cert disables verification on the > PKIX chain unless the 'preferences' flag is set. This flag will be buried in > a base64 encoded sub-field encoding. What is the alternative? I'm constantly hearing some folks that want to obtain DNSname-constrained organizational CA-certs signed under one of the pre-configured trust anchors so that their (DNS) admin can issue server certs without involvement of commercial CAs. Such CA-certs will probably sell at a significant premium. Should the IETF really define TLS technology in a fashion where everyone will have to buy out of slavery from a commercial CA oligopoly at a significant premium for every DNS domain one operates? It is a "trade-off", to hold the whole world hostage to the CA oligopoly in order to keep the initial investment (the "Coasean floor"[*]) high for only one specific impersonation attack, but I'm not convinced that this particular approach is the the best solution or the only solution and that the benefit is worth the cost. I could imagine that it appeals to top-level management, because they do not like to worry about outsourcing stuff (like DNS administration) or worry about making employees (like DNS admins) unhappy. -Martin [*] There was an article about "Coasean floor" in Bruce Schneiers Dec-2008 Cryptogram http://www.schneier.com/crypto-gram-0812.html#7 From marsh@extendedsubset.com Tue Oct 5 19:04:39 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078303A6D27; Tue, 5 Oct 2010 19:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.517, 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 7PL6f4oHDsHp; Tue, 5 Oct 2010 19:04:36 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 938193A6C0A; Tue, 5 Oct 2010 19:04:36 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1P3JNv-000AbN-CR; Wed, 06 Oct 2010 02:05:35 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id ECA496018; Wed, 6 Oct 2010 02:05:32 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18A3yYFcT2jzaNQV+n1e3ipTljIWbhA94M= Message-ID: <4CABD96C.3060007@extendedsubset.com> Date: Tue, 05 Oct 2010 21:05:32 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: mrex@sap.com References: <201010051946.o95JkteM009316@fs4113.wdf.sap.corp> In-Reply-To: <201010051946.o95JkteM009316@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 06 Oct 2010 08:05:39 -0700 Cc: DPKemp@missi.ncsc.mil, dnsop@ietf.org, saag@ietf.org, pkix@ietf.org, Phillip Hallam-Baker , tls@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 02:04:39 -0000 On 10/05/2010 02:46 PM, Martin Rex wrote: > > The DNS admin that controls A can always get a perfectly valid > certificate B issued and successfully impersonate all services > offered on servers in his DNS domain. By most people's definition, it's not "unauthorized impersonation" if the DNS admin does it Most people seem to be under the impression that current DNS and TCP/IP provides such a degree of security that it's "highly improbable" that there will be an active attack on their server's incoming connections. I'm not saying this is correct, only that it seems to be the conventional wisdom. There may be some organizations that separate the duties of DNS administration and key generation, but in general I'd think that organizations operating https servers are more concerned about getting their domain name stolen than losing control of the PKI chain of trust. > Because of this characteristic > of the TLS PKI, it doesn't matter how much scrutiny the CAs apply, > if you can not trust the DNS admin, you loose. So you seem to be saying that because some currently widely-trusted CAs will issue a new cert to an attacker able to receive email at the target domain (e.g. by controlling its DNS as resolved by the attacker's preferred CA) that nothing which is built on the current PKI is usefully authenticated. Also, DNS admins must be considered possible attackers. There's probably a lot of truth in there (or maybe I'm not understanding you correctly), but it seems like that line of reasoning isn't very useful. It could be used to support any conclusion. "PKI cert auth is no more secure than SMTP email" -> "PKI cert auth is no more secure than DNS" -> "https is no more secure than DNS" -> "no point in using HTTPS authentication" -> "no point in using HTTPS encryption" -> "we should all give up and go home". No doubt I feel like that some days. Let's keep in mind the goal of bootstrapping whatever the current system is to a higher level the security and efficiency for everyone. Considering where we are now, this is probably an achievable goal. > Requiring the involvement of a pre-trusted commercial CA makes > it less attractive to DNS admins to abuse their position and > harder for attackers that manage to modify DNS records of > DNSSEC signed zones to impersonate servers in that DNS zone. Is this the old security - ease of use tradeoff? Is the solution to increase the cost and difficulty of setting up an authenticated server? If so, how much will it take? I'm extremely skeptical of any system which purports to enable "opt-in" authentication. An attacker can usually just opt-out. > Obtaining CA-signed server certs may require "official procurement", > so the issuance of the server certs goes on record at the issuing CA > and the domain owners procurement. This could serve as a deterrent > for outsourced DNS services or unhappy DNS admins. This doesn't seem like a significant factor to me. > I'm constantly hearing some folks that want to obtain DNSname-constrained > organizational CA-certs signed under one of the pre-configured trust anchors > so that their (DNS) admin can issue server certs without involvement > of commercial CAs. Such CA-certs will probably sell at a significant > premium. Rumor has it that money talks with these CAs. Some will even sell you the right to issue certs for other domains (i.e., your very own sub-CA) for the right price. > Should the IETF really define TLS technology in a fashion where > everyone will have to buy out of slavery from a commercial CA oligopoly > at a significant premium for every DNS domain one operates? Well, when you put it that way... > It is a "trade-off", to hold the whole world hostage to the CA oligopoly > in order to keep the initial investment (the "Coasean floor"[*]) high > for only one specific impersonation attack, Is there another type of impersonation attack on TCP port 443? I think I'm not understanding what you're saying here. > but I'm not convinced that > this particular approach is the the best solution or the only solution > and that the benefit is worth the cost. I could imagine that it > appeals to top-level management, because they do not like to worry > about outsourcing stuff (like DNS administration) or worry about > making employees (like DNS admins) unhappy. Again, it doesn't make sense to me that the security model for protecting TCP port 443 should be optimized to allow for untrusted DNS/DNSSEC admins. But I can't tell if we're agreeing on this or not. - Marsh From pgut001@cs.auckland.ac.nz Wed Oct 6 08:22:29 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8742A3A7115; Wed, 6 Oct 2010 08:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEJkXRspUAvw; Wed, 6 Oct 2010 08:22:27 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id D5C853A7148; Wed, 6 Oct 2010 08:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1286378608; x=1317914608; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20dnsop@ietf.org,=20mstjohns@comcast.net,=20pkix@iet f.org,=20saag@ietf.org,=0D=0A=20=20=20=20tls@ietf.org |Subject:=20Re:=20[saag]=20[pkix]=20[TLS]=20Cert=20Enumer ation=20and=20Key=20Assurance=20With=20DNSSEC |In-Reply-To:=20<20101004182935.9E23A3A705F@core3.amsl.co m>|Message-Id:=20|Date:=20Thu,=2007=20Oct=202010=2004:23:25=20+1 300; bh=fwqRS7JTQ84AaGuNs6ko3D2cytteAbjqJpC+ki2mA50=; b=WfY0vcIRy09TgoTI5wTSIVU1hutsqzo1dPZwuOAELQMQy4gZKQ37P30L t0FrMtbf1drNNMQRt1S/6SY85ccBh1iABWREi9WXrcTtBVjVQjqfgIwN3 dQWj0ARIvML4EsgOdQAeh0cxpy0tSJfCjDQSTnRQPwySZhNJIpOP08Pej c=; X-IronPort-AV: E=Sophos;i="4.57,290,1283688000"; d="scan'208";a="30004051" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Oct 2010 04:23:25 +1300 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1P3Vq1-0000V9-Gc; Thu, 07 Oct 2010 04:23:25 +1300 From: Peter Gutmann To: dnsop@ietf.org, mstjohns@comcast.net, pkix@ietf.org, saag@ietf.org, tls@ietf.org In-Reply-To: <20101004182935.9E23A3A705F@core3.amsl.com> Message-Id: Date: Thu, 07 Oct 2010 04:23:25 +1300 Subject: Re: [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 15:22:29 -0000 Michael StJohns writes: >DNSSEC seems to be picking on PKIX and vice versa - maybe the right answer is >both? Maybe the right answer is a paddling pool full of jello and Marquess of Queensberry rules? Peter (just adding to the available options a bit). From yaronf.ietf@gmail.com Wed Oct 6 14:17:00 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B023A7147; Wed, 6 Oct 2010 14:17:00 -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 QnxdQCLQqM6P; Wed, 6 Oct 2010 14:16:59 -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 053223A71E5; Wed, 6 Oct 2010 14:16:57 -0700 (PDT) Received: by fxm6 with SMTP id 6so9814fxm.31 for ; Wed, 06 Oct 2010 14:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=lnSVHYR12MIJciOaVQlrO+vYpkQLQPf2U6qFCEiOJTk=; b=XwE6DBl33CHleM9lZrdO/+9g8Xzn0WGh8HdbmLN8QorQogLysEQffyg+DbD6mPLC50 CYFU4T1+nWmZyJr+PWjoEKCi+WHWkvQtUTRa8/7V6hAAbWFwfzxf/y10oPrICYt6QdVJ Ynq4/uZYPLA+n/q1yW6fvpIDalV2ZE+K0S/I4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MQoYHjh4DcF5HgD8Aaof+J4O3py1qPT2dGDcpte6qSksVz6vLM1xCW91p/walRjDL4 U3cpm24VjjhJjfSZfrq37K55eZsQE6rrBwk34AjKtsR6tYc1pIJSdceO1sVJi9HtXOdx +Eve86cB8oL+q3ks7og5SYd/VArhoucMhejeQ= Received: by 10.223.109.141 with SMTP id j13mr13126150fap.39.1286399872972; Wed, 06 Oct 2010 14:17:52 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-181-39-14.red.bezeqint.net [79.181.39.14]) by mx.google.com with ESMTPS id u8sm686757fah.36.2010.10.06.14.17.49 (version=SSLv3 cipher=RC4-MD5); Wed, 06 Oct 2010 14:17:51 -0700 (PDT) Message-ID: <4CACE77B.80804@gmail.com> Date: Wed, 06 Oct 2010 23:17:47 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: mrex@sap.com References: <201010050046.o950kBPe005266@fs4113.wdf.sap.corp> In-Reply-To: <201010050046.o950kBPe005266@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org, dnsop@ietf.org, Michael StJohns , saag@ietf.org, tls@ietf.org Subject: Re: [saag] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 21:17:00 -0000 People keep referring to the 100+ vendor CA jungle. It is somewhat impolite to point it out, but there are very few major vendors in this space, and these vendors have been implicated in some of the most publicized attacks. In some cases, hiding behind a "low-cost" brand name. In other words, the problem with the TLS PKI is not (only) the small fish. Thanks, Yaron On 10/05/2010 02:46 AM, Martin Rex wrote: [...] > > Conceptually, limiting the certificates that can be used to provide > servers on specific DNS hostnames to certificates explicitly listed > by the DNS admin would significantly reduce the huge attack surface > of the existing "TLS PKI" with>100 independent pre-configured > trust-anchors in most TLS client software. > From turners@ieca.com Wed Oct 6 18:19:29 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3CBD3A7258 for ; Wed, 6 Oct 2010 18:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 ZV+nv6ZD3vl2 for ; Wed, 6 Oct 2010 18:19:29 -0700 (PDT) Received: from smtp112.biz.mail.sp1.yahoo.com (smtp112.biz.mail.sp1.yahoo.com [69.147.92.225]) by core3.amsl.com (Postfix) with SMTP id 108CE3A6D04 for ; Wed, 6 Oct 2010 18:19:29 -0700 (PDT) Received: (qmail 77862 invoked from network); 7 Oct 2010 01:20:30 -0000 Received: from thunderfish.local (turners@96.241.10.225 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 06 Oct 2010 18:20:30 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: QKXUOusVM1nbuDREagTxys3aRke9JzhXZ5XaeNC3YpeXqyi wr8vsbqWjtb6es9GXpHSdjZrShr.lFVavc2XLLNYV95JuCY1vubjdrEst6D4 d_Pft0f3a4Z0tXZGRkeDTz6U.HT.iIi7EhwQG4EWiQz.3ELSDzImqvDw6O4S vU18SMs4hY4ZQSuylfhbrL2K_w1rR4yh1TA8GsSETBO16zGPdhJF3ZA1LCFa dSRnXJ6tQeKYMcWkuiAqmlm1rig255bxJoapqsF1i3uQO0AU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CAD205D.6090701@ieca.com> Date: Wed, 06 Oct 2010 21:20:29 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: cfrg@irtf.org, saag@ietf.org References: <4CA65AD7.80300@ieca.com> <4CA8ECA9.9020201@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 01:19:29 -0000 Paul Hoffman wrote: > At 9:50 PM +0100 10/3/10, Tobias Gondrom wrote: >> Must say I agree with Paul's concerns below (and in particular >> hesitated too when I read the intended "MUST NOT" effect of a guidance >> informational draft on standards documents). >> However, I think the general idea to write a guidance ID is a good idea >>from Tim, et al. > > Fully agree (certainly more useful than such guidance coming from you or I). However, it would be nice if the document said why they were the ones writing it. The 2119 language should not have been included. We're only trying to update the security considerations not provide mandates. This draft should have followed the same format as the recent MD2/4/5 security consideration update drafts and those don't include 2119 language. I'm sorry for any confusion. We wrote this draft because somebody asked for it as part of their comments on the MD2/4/5 drafts (and I thought it was low hanging fruit). I assure you there is no sinister plan. We'll update the draft with the Paul's wording, remove the 2119 reference, and address off-list comments from Ran and Sheila. spt From turners@ieca.com Fri Oct 8 14:02:03 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A66D3A696D for ; Fri, 8 Oct 2010 14:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.719 X-Spam-Level: X-Spam-Status: No, score=-102.719 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 zTn1FdJIOg9p for ; Fri, 8 Oct 2010 14:02:01 -0700 (PDT) Received: from smtp114.biz.mail.mud.yahoo.com (smtp114.biz.mail.mud.yahoo.com [209.191.68.79]) by core3.amsl.com (Postfix) with SMTP id A62EA3A696C for ; Fri, 8 Oct 2010 14:02:01 -0700 (PDT) Received: (qmail 2858 invoked from network); 8 Oct 2010 21:02:56 -0000 Received: from thunderfish.local (turners@96.241.4.230 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 08 Oct 2010 14:02:56 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: kBGrr6gVM1nVtMl1e0BH7JwHqcEtjtq3Nekzr6r_hob6ywJ HH3pqM7RzhjoAOnlJZqm6TJ4hVzqTSscH9B1feMHOOLviYms09d0SDR3PeDb M62XL06.jZv0pchWCud3OxZ55JXbcmpT7.jYTnBLPmrizLDGFPdvY0XA40ub vdkebJFoc6rbA9Z0C0k0TOo8HstQEXOjuur3rngmL.1YJZQGRpgEPMyR4PDu sSPIt3UJHXFQAUmqdTgdG7T6c8pXQzccRpWvyAyJUtUEuQWHMGX__RlB.cxO 7a4MigNeN7cJVt.NIazFXyOpgOIkEZlcS6qa0vkPF9PVMRaLf.7wQgw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CAF86FF.8020909@ieca.com> Date: Fri, 08 Oct 2010 17:02:55 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Sean's AD Notes 2010-10-08 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 21:02:03 -0000 These notes are identical (minus the wiki links) to those posted on: http://trac.tools.ietf.org/area/sec/trac/wiki/SeansMonthlyUpdate. Note that there's also a blog with an RSS feed at: http://trac.tools.ietf.org/area/sec/trac/blog = Sean Turner's Monthly AD Notes - 2010-10-08 = Here's my not-so-monthly AD notes. It's a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. == MISC NOTES == * IAB/IESG Joint Design Session on Forwarding Plane Operations, Administration and Maintenance to be held Oct 12-15 at George Mason University in Fairfax, Virginia, USA. Initial announcement can be found here: https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=8272&tid=1286570995. Dedicated mailing list info can be found here: https://www.ietf.org/mailman/listinfo/oam. * IAB/W3C/ISOC/MIT Internet Privacy Workshop on Dec 8-9 at MIT, Cambridge, Massachusetts, USA. Initial announcement can be found here: https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=8382&tid=1286571183. * IETF 79 planning continues with Tim: SAAG presentations. * Participated in weekly calls with Tim. * Tim and I resolved a couple hundred errata. There were so many because more than one was multi-part and we had to split them apart. We could not have done this without the help of the document authors. Many thanks! FYI, here's a break down of the errata by Area: 21 - Applications, 0 - General, 175 - Internet, 26 - Operations & Management, 56 - Real-time Applications & Infrastructure, 99 - Routing, 9 - Security, and 43 - Transport. == WORKING GROUPS == === DKIM === * draft-ietf-dkim-mailinglists: Has been revised a couple of times. LOTS of email on the DKIM list. * draft-ietf-dkim-4871bis: Has been posted and revised a couple of times. Currently in WG LC that ends 2010-10-22. * draft-ietf-dkim-implementation-report: Has been posted a revised a couple of times. Currently in WG LC that ends 2010-10-22. * Errata 1532 and 1596: Determined that these should be hold for document update (HFDU). NOTE: The implementation report contains data on over 2 billion (and yes that's a "b") messages. I personally think progressing RFC 4871 to PS should be a slam dunk. The implementation report won't be published as an RFC, but will instead live on here: http://www.ietf.org/iesg/implementation-report.html. The implementation report will be referenced in the IETF LC for 4871bis === EMU === * draft-ietf-emu-eaptunnel-req: Waiting for proto write-up. Since 2010-07-13. * draft-ietf-emu-chbind: Expecting a new version before IETF 79. IPSECME * RFC5930 (was draft-ietf-ipsecme-aes-ctr-ikev2) published. * RFC5996 (was draft-ietf-ipsecme-ikev2bis) published. * RFC5998 (was draft-ietf-ipsecme-eap-mutual) published. * draft-ietf-ipsecme-roadmap: In RFC editor queue (http://www.rfc-editor.org/queue2.html#draft-ietf-ipsecme-roadmap). * draft-ietf-ipsecme-ipsec-ha: In RFC editor queue (http://www.rfc-editor.org/queue2.html#draft-ietf-ipsecme-ipsec-ha). * draft-ietf-ipsecme-ipsecha-protocol: Initial version posted. * draft-ietf-ipsecme-failure-detection-00: Initial version posted A related non-WG item: * draft-nir-ipsecme-childless: Was from the Independent Stream. In RFC editor queue (http://www.rfc-editor.org/queue2.html#draft-nir-ipsecme-childless) === ISMS === * RFC5953 (was draft-ietf-isms-dtls-tm) published. * draft-ietf-isms-radius-vacm: In RFC editor queue (http://www.rfc-editor.org/queue2.html#draft-ietf-isms-radius-vacm). === KEYPROV === (I know it's Tim's but I am following it closely) * draft-ietf-keyprov-dskpp: In RFC editor queue (http://www.rfc-editor.org/queue2.html#draft-ietf-keyprov-dskpp). * draft-ietf-keyprov-pskc: In RFC editor queue (http://www.rfc-editor.org/queue2.html#draft-ietf-keyprov-pskc). * draft-ietf-keyprov-symmetrickeyformat: In RFC editor queue (http://www.rfc-editor.org/queue2.html#draft-ietf-keyprov-symmetrickeyformat). === LTANS === (This is Tim's, but I thought it of interest) * draft-ietf-ltans-xmlers: Has passed WG LC and will be forwarded to Tim soon. If the authors wish to progress the remaining drafts (draft-ietf-ltans-validate and draft-ietf-ltans-ari), then Tim has agreed to AD sponsor them. It is expected that this WG will be closed once -xmlers is published. === SASL === * SASL/KITTEN merged. === SMIME === (This is Tim's, but I thought it of interest) * RFC5990 (was draft-ietf-smime-cms-rsa-kem/) published. This was the final deliverable for this WG. The chairs have requested the WG be closed. === SYSLOG === * draft-ietf-syslog-dtls: In RFC editor queue (http://www.rfc-editor.org/queue2.html#draft-ietf-syslog-dtls). * Though all of the WG's work items are approved, the WG not be closed until the syslog-dtls I-Ds is actually published. === TLS === * draft-ietf-tls-rfc4366-bis: In RFC editor queue (http://www.rfc-editor.org/queue2.html#draft-ietf-tls-rfc4366-bis). * draft-ietf-tls-cached-info: No updates. * draft-ietf-tls-heartbeat: No updates. * draft-ietf-tls-rfc4347-bis: No updates. * draft-ietf-tls-ssl2-must-not: Initial update posted. New version expected shortly. == OTHER DOCUMENTS == * draft-hoffman-tls-master-secret-input: In RFC editor queue (http://www.rfc-editor.org/queue2.html#draft-hoffman-tls-master-secret-input). Waiting for dt:draft-ietf-tls-rfc4347-bis-04. * draft-josefsson-pbkdf2-test-vectorshttp: I sponsored this individual draft. It passed a 4 week IETF LC and is now in the RFC editor queue (http://www.rfc-editor.org/queue2.html#draft-josefsson-pbkdf2-test-vectors) * draft-mavrogiannopoulos-rfc5081bis: I sponsored this individual draft. It passed a 4 week IETF LC. There is one remaining discuss to be resolved, but I believe it will be cleared once the AD holding the discuss returns from vacation. * draft-josefsson-rc4-test-vectors: I'm going to AD sponsor this individual draft. I'm waiting for the authors to fix some nits and then I'm going to ask for an IETF LC. * draft-igoe-secsh-x509v3: I'm going to AD sponsor this individual draft. Waiting for the authors to call it done. The authors of the following drafts have asked that I AD sponsor their individual drafts. The authors requested standards track, but after querying the community I think it's more appropriate that these go informational track. * draft-nsri-tls-aria: An initial draft was posted for TLS cipher suite for the Korean ARIA algorithm. The authors placed all the cipher suites they could want in one document (it's ~50 suites). That should make it easier for implementers. The authors have requested review from the TLS WG. * draft-seokung-ipsecme-seed-ipsec-modes: They've been waiting on me to figure out whether this should go informational or standards track. As noted above, I prefer individual. I'll await a new version before progressing. Since 2010-09-24. * draft-kato-ipsec-camellia-gcm, draft-kato-ipsec-camellia-cmac96and128, draft-kato-tls-camellia-ecc-sha, draft-kato-tls-camellia-gcm, draft-kato-tls-camellia-psk: They've been waiting on me to figure out whether this should go informational or standards track. As noted above, I prefer individual. Further, I'd prefer to see one document for ipsec and another for tls. I don't see the need to have 5 IDs when we could do 2. Since 2010-09-24. == DISCUSSES == As an AD, the more DISCUSS positions you enter the more work you have to do (an fyi for all those would be ADs). === NEW === * draft-ietf-csi-hash-threat: Reviewed the new draft and there were still some issues. Since 2010-07-14. * draft-ietf-avt-rtp-ipmr: New version posted today. I'll review it shortly. 2010-10-08. * draft-ietf-6lowpan-routing-requirements: Reviewed new version. Still has some issues. 2010-08-05. * draft-ietf-csi-proxy-send: This one is on me. Need to ensure their changes are okay. Since 2010-09-28. * draft-ietf-mif-problem-statement: Awaiting new version. Since 2010-08-26. * draft-ietf-avt-srtp-not-mandatory: Awaiting new version. Since 2010-08-26. * draft-ietf-geopriv-arch: Awaiting new version. Since 2010-09-08. * draft-cakulev-mikey-ibake: Awaiting new version. Since 2010-09-08. * draft-ietf-fecframe-framework: Awaiting new version. Since 2010-09-08. * draft-ietf-opsec-igp-crypto-requirements: Awaiting new version. Since 2010-10-07. * draft-ietf-grow-mrt: Awaiting new version. Since 2010-10-07. === OLD === * draft-cheshire-dnsext-nbp: The state has changed to AD Evaluation so it's fallen of my DISCUSS page, but I still hold part of Pasi's DISCUSS. 2010-04-08. * draft-denenberg-mods-etc-media-types: Awaiting response from authors. 2010-04-29. This one will probably be pinned for a while waiting for OASIS to stabilize a draft. === DEAD === * draft-ietf-avt-register-srtp-02: Responsible AD changed status to Dead. spt From dougb@dougbarton.us Sun Oct 10 21:09:52 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D0D43A68BD for ; Sun, 10 Oct 2010 21:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[AWL=-0.323, 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 zPrpZjef-SOB for ; Sun, 10 Oct 2010 21:09:52 -0700 (PDT) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by core3.amsl.com (Postfix) with ESMTP id B12633A6407 for ; Sun, 10 Oct 2010 21:09:48 -0700 (PDT) Received: (qmail 1544 invoked by uid 399); 11 Oct 2010 04:10:57 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 11 Oct 2010 04:10:57 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CB28E5E.9000606@dougbarton.us> Date: Sun, 10 Oct 2010 21:11:10 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: der Mouse References: <201010050046.o950kBPe005266@fs4113.wdf.sap.corp> <79D1362B-40D5-4990-BD7F-913903837907@jpl.nasa.gov> <201010050800.EAA11862@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201010050800.EAA11862@Sparkle.Rodents-Montreal.ORG> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 14 Oct 2010 08:08:07 -0700 Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org Subject: Re: [saag] [DNSOP] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 04:09:52 -0000 On 10/5/2010 1:00 AM, der Mouse wrote: > But the original statement was that DNSSEC provides "secure" > association from name to IP. This is a stronger property than > providing secure distribution of name-to-IP mapping information; it > also implies that the creation of that information and its injection > into the distribution mechanisms are "secure" (whatever that means - I > note that none of these say what they are talking about being secure > against; perhaps I'm just missing context). Sorry, almost nothing you wrote above is true. The only thing that DNSSEC has ever claimed to be able to do is provide a way for the end user of the DNS data to prove to herself that the data they received is the data that the administrator of the zone wanted them to have. The use of the word "security" in the name of the protocol extension was an incredibly unfortunate choice because it conveys all of the misunderstandings you listed above, and a lot more. Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From turners@ieca.com Mon Oct 18 16:32:27 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3723A6C06 for ; Mon, 18 Oct 2010 16:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 fKj+qJOR-m6u for ; Mon, 18 Oct 2010 16:32:26 -0700 (PDT) Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id DC0F43A6C2F for ; Mon, 18 Oct 2010 16:32:10 -0700 (PDT) Received: (qmail 56087 invoked from network); 18 Oct 2010 23:33:37 -0000 Received: from thunderfish.local (turners@96.241.14.186 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 18 Oct 2010 16:33:37 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: zbqmzRwVM1nqT2wQ3zC2BaJIfjZhDR6RKiHMMnafDpgS.3v chzbRmWn81jid_YXdBYDK0wmoF0zA0HpGg26X2MbrPaelLmqMmLuJ5lDOpd8 OGPo6kQZ2feph4ueztOgPNPHUYwBe7m48F584kTEkdxhzNCs8P.BbTfvMOzn ksFqEDWVyEN0PBjGAtbOGxGVrdbmUnuaTjLtvdEsm_oJRKuwe8JafYYVe_ts srvpK5FAfXss7Fb18.uSbID41w6NXL31ZY5O3GFerSVIY9h_SVuE8ZsiIGyw v.bRXphssp1i.yTyWW9eG__7h79RuHUHxhNSqVVDk71_vFMmHJ3WuuEW3HGm XSux.KU4bSW2hP8bM9LFUt8ADvyH44lgXRcZkPQarxk1SQOploJGJl_QxB9Q 4VjzWxCnXu9kceh5fhODMXaFkMN8WfLzj32dfJDhflAHvOGXYU0Q_jKR0 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CBCD950.7000805@ieca.com> Date: Mon, 18 Oct 2010 19:33:36 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: saag@ietf.org, cfrg@irtf.org Content-Type: multipart/mixed; boundary="------------050800080101000704030301" Subject: [saag] Fwd: I-D ACTION:draft-turner-md4-to-historic-06.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 23:32:27 -0000 This is a multi-part message in MIME format. --------------050800080101000704030301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In case you missed it in the md2-to-historic draft emails, we've also published a draft that recommends moving MD4 to historic. It follows the same format as the md2-to-historic-draft. Comments are welcome. Please send comments to saag@ietf.org. Thanks, spt -------- Original Message -------- Subject: I-D ACTION:draft-turner-md4-to-historic-06.txt Date: Mon, 18 Oct 2010 13:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MD4 to Historic Status Author(s) : S. Turner, L. Chen Filename : draft-turner-md4-to-historic-06.txt Pages : 10 Date : 2010-10-18 This document recommends the retirement of MD4 and discusses the reasons for doing so. This document recommends RFC 1320 be moved to Historic status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-md4-to-historic-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------050800080101000704030301 Content-Type: Message/External-body; name="draft-turner-md4-to-historic-06.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-turner-md4-to-historic-06.txt" Content-Type: text/plain Content-ID: <2010-10-18130926.I-D@ietf.org> --------------050800080101000704030301 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------050800080101000704030301-- From stpeter@stpeter.im Wed Oct 20 11:22:52 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECFE93A6845; Wed, 20 Oct 2010 11:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 4C1Mi7wP-7Ft; Wed, 20 Oct 2010 11:22:49 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 489203A67EF; Wed, 20 Oct 2010 11:22:49 -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 9A8EB40074; Wed, 20 Oct 2010 12:31:48 -0600 (MDT) Message-ID: <4CBF33D5.2060806@stpeter.im> Date: Wed, 20 Oct 2010 12:24:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "tls@ietf.org" , pkix@ietf.org, saag@ietf.org X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020005090208090202020700" Subject: [saag] Fwd: [certid] Fwd: I-D Action:draft-saintandre-tls-server-id-check-10.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 18:22:52 -0000 This is a cryptographically signed message in MIME format. --------------ms020005090208090202020700 Content-Type: multipart/mixed; boundary="------------020505010406080400050504" This is a multi-part message in MIME format. --------------020505010406080400050504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In case your eyes glazed over at the long threads about this I-D, here is the resulting I-D and diff from the version that went through IETF Last Call... -------- Original Message -------- Subject: [certid] Fwd: I-D Action:draft-saintandre-tls-server-id-check-10.txt Date: Wed, 20 Oct 2010 10:36:05 -0600 From: Peter Saint-Andre To: IETF cert-based identity Finally! The diff is here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-saintandre-tls-server-id-check= -10 -------- Original Message -------- Subject: I-D Action:draft-saintandre-tls-server-id-check-10.txt Date: Wed, 20 Oct 2010 09:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) Author(s) : P. Saint-Andre, J. Hodges Filename : draft-saintandre-tls-server-id-check-10.txt Pages : 46 Date : 2010-10-20 Many application technologies enable a secure connection between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies best current practices for representing and verifying the identity of application services in such interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-= 10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------020505010406080400050504 Content-Type: Message/External-body; name="draft-saintandre-tls-server-id-check-10.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-saintandre-tls-server-id-check-10.txt" Content-Type: text/plain Content-ID: <2010-10-20092452.I-D@ietf.org> --------------020505010406080400050504 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSS1ELUFu bm91bmNlIG1haWxpbmcgbGlzdApJLUQtQW5ub3VuY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UKSW50ZXJuZXQtRHJhZnQg ZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQKCg== --------------020505010406080400050504 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KY2VydGlk IG1haWxpbmcgbGlzdApjZXJ0aWRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jZXJ0aWQKCg== --------------020505010406080400050504-- --------------ms020005090208090202020700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy MDE4MjQyMVowIwYJKoZIhvcNAQkEMRYEFOidw9Yu2eHXBggcrtOIhIvfoVopMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQA7idUF/PfQlodhjDjAgfHRKV7RCYZYLOw46WkokdH1ysAmVXNNvuxmJTHP bPvV/ReuJCgQQ0aoSCoje28ajAhYO4/ySKdXIBNCxnCXFulQj+/ALUyKE5a10OLbQTA8a8f5 egpOilm5QdLBaU63LySaQVVMu0R/Abyp78MEvxkgx1cq3Z+2IOJkk5O/L9uu4hOvmKIpmVyp I+S0RvhivzsUBTsC9J3JZJOt/7RP9t5o8WVd+ROJ6gdMgfw1TYKzHTHQq6Cgc3+gQXArFIA+ pClr+hrE4liVZXusn/e8JNYq+MhNDzg+tT1HobUF1uKPGh05aOfV64JN2j5TrlodLDZzAAAA AAAA --------------ms020005090208090202020700-- From turners@ieca.com Wed Oct 20 18:01:00 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCE73A6957 for ; Wed, 20 Oct 2010 18:01:00 -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=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 nrL9CQjGuyX0 for ; Wed, 20 Oct 2010 18:00:59 -0700 (PDT) Received: from nm24-vm0.bullet.mail.ac4.yahoo.com (nm24-vm0.bullet.mail.ac4.yahoo.com [98.139.53.222]) by core3.amsl.com (Postfix) with SMTP id 3BF663A695F for ; Wed, 20 Oct 2010 18:00:59 -0700 (PDT) Received: from [98.139.52.197] by nm24.bullet.mail.ac4.yahoo.com with NNFMP; 21 Oct 2010 01:02:30 -0000 Received: from [98.139.52.152] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 21 Oct 2010 01:01:25 -0000 Received: from [127.0.0.1] by omp1035.mail.ac4.yahoo.com with NNFMP; 20 Oct 2010 22:56:48 -0000 X-Yahoo-Newman-Id: 620193.1805.bm@omp1035.mail.ac4.yahoo.com Received: (qmail 77171 invoked from network); 20 Oct 2010 22:13:22 -0000 Received: from thunderfish.local (turners@96.231.127.199 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 20 Oct 2010 15:13:22 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: PD1s0kIVM1lTcaLRFUT._Gxv4Pb8gdSYEPhUJyRNxKk3lDl hoNH4bke1ETsFEuodI002g5jtPNS.xj5hECBV98V10YUDoLPnW9pKGWLrCxV Of8tWedd0LIAmA7t9RFv6PNUwy.Oh33qrlXpogTHGDqr4_WND7s698m.QqpP hTB2_TrpiVBalONAUYKde6Bym2w05FmQkYj40ItdP2K7XPFbwFBsKiqXZPbq IBlgETIl.DaheOpOCXoddh6aYJ.4KJGG6sXrxPYn9lQP50.0pW9ClWwzQrFM - X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CBF6981.1090809@ieca.com> Date: Wed, 20 Oct 2010 18:13:21 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: saag@ietf.org, cfrg@irtf.org Content-Type: multipart/mixed; boundary="------------040909050509070905080400" Subject: [saag] Fwd: I-D ACTION:draft-turner-md5-seccon-update-05.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 01:01:00 -0000 This is a multi-part message in MIME format. --------------040909050509070905080400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In case you missed it in the md2-to-historic draft email thread, we've also published a draft that updates the MD5 security considerations. Comments are welcome. Please send comments to saag@ietf.org. Thanks, spt -------- Original Message -------- Subject: I-D ACTION:draft-turner-md5-seccon-update-05.txt Date: Wed, 20 Oct 2010 14:30:22 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms Author(s) : S. Turner, L. Chen Filename : draft-turner-md5-seccon-update-05.txt Pages : 7 Date : 2010-10-20 This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-md5-seccon-update-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------040909050509070905080400 Content-Type: Message/External-body; name="draft-turner-md5-seccon-update-05.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-turner-md5-seccon-update-05.txt" Content-Type: text/plain Content-ID: <2010-10-20142350.I-D@ietf.org> --------------040909050509070905080400--