From nobody Tue Oct 7 10:13:40 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F010B1ACED5 for ; Tue, 7 Oct 2014 10:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlPF_ODFspa3 for ; Tue, 7 Oct 2014 10:13:34 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000C71ACEB4 for ; Tue, 7 Oct 2014 10:13:33 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s97HDVTY017242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 7 Oct 2014 10:13:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6767D274-D06D-4938-9126-7221ED7E3165@vpnc.org> Date: Tue, 7 Oct 2014 10:13:30 -0700 To: DNSEXT Group Working Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/iZ1eVMlrnCrz0D-JpP1LvVA5Dfk Subject: [dnsext] How are people implementing hold-down in RFC 5011? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 17:13:39 -0000 Greetings. In reading RFC 5011 more carefully, I am finding that some of = the wording is confusing (possibly just to me). I have a few questions = for people who have implemented it in systems, but also want to hear = from the greater DNS community. Section 2.2 says: Assume two trust point keys A and B. Assume that B has been compromised. An attacker could generate and add a new trust anchor key C (by adding C to the DNSKEY RRSet and signing it with B), and then invalidate the compromised key. This would result in both the attacker and owner being able to sign data in the zone and have it accepted as valid by resolvers. I am assuming that "invalidate" means "revoke". Pictorially, I think = this means the following progression in time: 1: Owner's zone: A signs (A B) 2: Attacker's zone: B signs (A Br C) (Here, "Br" means "B with the REVOKE bit set".) Immediately after the relying party has seen (2), B can never be trusted = again, even while they are waiting for the hold-down timer for adding C. Later in Section 2.2, it says: In the given example, the zone owner can recover from a compromise by revoking B and adding a new key D and signing the DNSKEY RRSet with both A and B. The time progression here sounds like: 1: Owner's zone: A signs (A B) 2a: Attacker's zone: B signs (A Br C) 2b: Owner's zone: B signs (Br) and A signs (A D) and B signs (A D) 2a happens before 2b because that is how the owner discovers that B was = compromised. I don't understand why B signs (A D) in 2b. B is already untrusted to = anyone who saw 2a, and is untrusted by anyone looking at all of 2b. = These instructions seem to be saying "put a signature into the zone that = cannot be validated". I would think that 2b should just be "B signs (Br) = and A signs (A D)", but that's not what the RFC says. So: has anyone implemented what the RFC says? If so, did you try it with = some validating resolvers? What were the results? Or: am I completely misreading something in this section? --Paul Hoffman= From nobody Tue Oct 7 13:03:55 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720BF1A8749 for ; Tue, 7 Oct 2014 13:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MISSING_MID=0.497, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3zIkBnPMPoO for ; Tue, 7 Oct 2014 13:03:51 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5242A1A1AB3 for ; Tue, 7 Oct 2014 13:03:51 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-07v.sys.comcast.net with comcast id 0L2C1p0032JGN3p01L3qHc; Tue, 07 Oct 2014 20:03:50 +0000 Received: from Mike-T530ssd.comcast.net ([74.121.22.10]) by resomta-ch2-10v.sys.comcast.net with comcast id 0L3f1p00L0D3YW201L3iq4; Tue, 07 Oct 2014 20:03:48 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 07 Oct 2014 16:03:53 -0400 To: Paul Hoffman , DNSEXT Group Working From: Michael StJohns In-Reply-To: <6767D274-D06D-4938-9126-7221ED7E3165@vpnc.org> References: <6767D274-D06D-4938-9126-7221ED7E3165@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412712230; bh=DHlnNChRjUDFEJJ/jMUsXB+zy/OBYBzw0HQN3y9zUu4=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=NOA/CMFhCwXPT5Mer/UKwI7+CGs1DyhmVCj0HgAUNRKDSeo6MaewndhIuD6ifVdjX J+qK4Ie1QdoxURhV/oN5fr6ncgez2jrmhPpQyowoGdAY1lnrPIYRCnCb/ryoShSq3u F4A2z61YtqznNLJOZmKvSgiN0Yy2r1aNgDOFf9tcpDlQR8rqC2RRnL6/acsUaj6TEo 86pf0tuTOBND3Jwn2aIka5pvs9JOjv1Y2oZ2cZkVVN3fgEti1KVx6GaTy50sx8tiy5 jeO2nH9JMjiJgL6OSbBWPUN3MvFEOwZeda4oAW9e9dr8i3vbiNGd3bwOQPrQigxhYB KND5WuebI+LSg== Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/nhAaZUNLLS7WKQnFxvSEhOOPxu8 Subject: Re: [dnsext] How are people implementing hold-down in RFC 5011? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 20:03:54 -0000 At 01:13 PM 10/7/2014, Paul Hoffman wrote: >Greetings. In reading RFC 5011 more carefully, I am finding that some of the wording is confusing (possibly just to me). I have a few questions for people who have implemented it in systems, but also want to hear from the greater DNS community. > >Section 2.2 says: > > Assume two trust point keys A and B. Assume that B has been > compromised. An attacker could generate and add a new trust anchor > key C (by adding C to the DNSKEY RRSet and signing it with B), and > then invalidate the compromised key. This would result in both the > attacker and owner being able to sign data in the zone and have it > accepted as valid by resolvers. > >I am assuming that "invalidate" means "revoke". Yes. >Pictorially, I think this means the following progression in time: > 1: Owner's zone: A signs (A B) > 1.5 Attacker's zone: B signs (B C) (This has to happen for the Add Hold down time until C becomes a valid trust anchor. In general this is going to be B and C sign (B, C) for the hold down period). >2: Attacker's zone: B signs (A Br C) >(Here, "Br" means "B with the REVOKE bit set".) 2 is actually B and C sign (Br C). >Immediately after the relying party has seen (2), B can never be trusted again, even while they are waiting for the hold-down timer for adding C. Revocation takes place immediately. Once the bit is set and validly signed, the key is revoked and can't be used for anything except signing the revocation. So in B and C sign (Br C), the signature over the keys by B only has impact on Br, The signature by C over the keys only has impact if C has already been added to the validators trust anchor set. >Later in Section 2.2, it says: > > In the given example, the zone owner can recover from a compromise by > revoking B and adding a new key D and signing the DNSKEY RRSet with > both A and B. > >The time progression here sounds like: > 1: Owner's zone: A signs (A B) > 2a: Attacker's zone: B signs (A Br C) > 2b: Owner's zone: B signs (Br) and A signs (A D) and B signs (A D) >2a happens before 2b because that is how the owner discovers that B was compromised. What happens at a validator depends on what the validator sees. In general this goes: A Signs (A B) B is compromised Owner: A and B sign (A Br D) - B is revoked and D starts its process of being added as a trust anchor. Attacker: B signs (B C) The key point is that if the validator sees even one of the "A and B sign (A Br D)" RRSets, then B is revoked and "B signs (B C)" will fail validation leading to C not being added to the trust anchor set. >I don't understand why B signs (A D) in 2b. B is already untrusted to anyone who saw 2a, and is untrusted by anyone looking at all of 2b. These instructions seem to be saying "put a signature into the zone that cannot be validated". I would think that 2b should just be "B signs (Br) and A signs (A D)", but that's not what the RFC says. You can't actually have two different versions of the DNSKEY RRSet being simultaneously offered by a single responder. You *can* have multiple signatures over a single DNSKEY RRSet. So the above is actually "A and B sign (A Br D)". It's also actually more like "A and B sign (Br D and Z)" where "Z" is one of the ZSKs. So you get "B signs Br to revoke itself", "A signs D to add D to the trust anchor set" and "A signs Z so that Z chains to the root of trust". That's expressed by a DNSKEY RRSet consisting of B with the revoke bit, D with the SEP bit and Z without the SEP bit with two RRSIG(DNSKEY) records consisting of a signature by A and a signature by B. Mike >So: has anyone implemented what the RFC says? If so, did you try it with some validating resolvers? What were the results? > >Or: am I completely misreading something in this section? > >--Paul Hoffman >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext From nobody Tue Oct 7 13:11:07 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4880D1A883B for ; Tue, 7 Oct 2014 13:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MISSING_MID=0.497, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ArN0QxdZi_l for ; Tue, 7 Oct 2014 13:10:52 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C141A882B for ; Tue, 7 Oct 2014 13:10:38 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-04v.sys.comcast.net with comcast id 0LAZ1p0042Fh1PH01LAemm; Tue, 07 Oct 2014 20:10:38 +0000 Received: from Mike-T530ssd.comcast.net ([74.121.22.10]) by resomta-ch2-08v.sys.comcast.net with comcast id 0LAS1p00W0D3YW201LAVSl; Tue, 07 Oct 2014 20:10:36 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 07 Oct 2014 16:10:41 -0400 To: Paul Hoffman , DNSEXT Group Working From: Michael StJohns In-Reply-To: <20141007200355.799B41A1A28@ietfa.amsl.com> References: <6767D274-D06D-4938-9126-7221ED7E3165@vpnc.org> <20141007200355.799B41A1A28@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412712638; bh=LAiRZI4jcN9d6YsUgA+ylo3/ncasifhkjAC5Hx1qlSM=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=LjwK1h0G3FmbHuyBFXe1p3a87q365ESJ20f7tKnTo0EL+thhurr/lWD3vYPRaXI9A sKHYBAXyVBsF9q5P5qGGPGumEclyIiMYaiLd/w4a3zc8Gl+kSMltfN1hONvVmxBE9/ qRCXNgt1dtoWZOdSZhwuEaXfqLw4+j+DAntMCu8NXHIhe/bnY3ATUP+uTS7cC8cYR7 ONQAU4NgCXNrjSONN6EZgkLvpWRSYAHhxXawaIWXWRTqk2FsbHy6On+YijBYmgbc+S KnWR5qsz6jmYSGuR/Fpqzi2usKUbk9n8ZGg6ryf3ifKmCSi6XTr9QWQtrTWG/DUyGo dPQfqr5iv39nA== Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/ODJpvDX34O-w0E0tdLBSCRQqohg Subject: Re: [dnsext] How are people implementing hold-down in RFC 5011? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 20:11:02 -0000 At 04:03 PM 10/7/2014, Michael StJohns wrote: >So the above is actually "A and B sign (A Br D)". It's also actually more like "A and B sign (Br D and Z)" where "Z" is one of the ZSKs. So you get "B signs Br to revoke itself", "A signs D to add D to the trust anchor set" and "A signs Z so that Z chains to the root of trust". Sorry - This is actually "A and B sign (A Br D and Z)". A signing key needs to be included in the DNSKEY RRSet even if its already accepted as a trust anchor. That's mainly so the key id reference of the RRSIG (DNSKEY) can find the appropriate public key for validation. Mike From nobody Tue Oct 7 16:57:35 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73DF1A8AA2 for ; Tue, 7 Oct 2014 16:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJYoj94jn0mU for ; Tue, 7 Oct 2014 16:57:32 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0104E1A889C for ; Tue, 7 Oct 2014 16:57:31 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s97NvRpP041572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Oct 2014 16:57:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <20141007200355.799B41A1A28@ietfa.amsl.com> Date: Tue, 7 Oct 2014 16:57:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51E89C93-5C03-4D02-B0FE-C1CBBC3ECA06@vpnc.org> References: <6767D274-D06D-4938-9126-7221ED7E3165@vpnc.org> <20141007200355.799B41A1A28@ietfa.amsl.com> To: Michael StJohns X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/xfCjRpv95ayzr-5hmvH4N93vfNg Cc: DNSEXT Group Working Subject: Re: [dnsext] How are people implementing hold-down in RFC 5011? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 23:57:34 -0000 Thanks for the clarifications. I still have a bunch of questions, and I = really do wonder if implementers agree with your interpretations. On Oct 7, 2014, at 1:03 PM, Michael StJohns = wrote: > At 01:13 PM 10/7/2014, Paul Hoffman wrote: >> Greetings. In reading RFC 5011 more carefully, I am finding that some = of the wording is confusing (possibly just to me). I have a few = questions for people who have implemented it in systems, but also want = to hear from the greater DNS community. >>=20 >> Section 2.2 says: >>=20 >> Assume two trust point keys A and B. Assume that B has been >> compromised. An attacker could generate and add a new trust anchor >> key C (by adding C to the DNSKEY RRSet and signing it with B), and >> then invalidate the compromised key. This would result in both the >> attacker and owner being able to sign data in the zone and have it >> accepted as valid by resolvers. >>=20 >> I am assuming that "invalidate" means "revoke".=20 >=20 > Yes. =20 >=20 >> Pictorially, I think this means the following progression in time: >> 1: Owner's zone: A signs (A B) >>=20 >=20 > 1.5 Attacker's zone: B signs (B C) > (This has to happen for the Add Hold down time until C becomes a valid = trust anchor. In general this is going to be B and C sign (B, C) for = the hold down period). There is nothing in the quoted paragraph from the RFC that indicates = that the attacker gets C to be a valid trust anchor. It sounds like you = meant to say "the attack is only going to work if a relying party trust = C, and that will only happen after the hold-down period, so the attacker = first introduces C, then only that has succeeded for some desired = targets, revokes B". >=20 >> 2: Attacker's zone: B signs (A Br C) >> (Here, "Br" means "B with the REVOKE bit set".) >=20 > 2 is actually B and C sign (Br C). When the RFC says "and signing it with B", it might be clearer if it = says "and signing it with B and C". It is far from clear which messages = from the attacker are for public consumption (which would be seen by the = zone owner) and which are meant for restricted relying parties.=20 >> Immediately after the relying party has seen (2), B can never be = trusted again, even while they are waiting for the hold-down timer for = adding C. >=20 > Revocation takes place immediately. Once the bit is set and validly = signed, the key is revoked and can't be used for anything except signing = the revocation. So in B and C sign (Br C), the signature over the keys = by B only has impact on Br, The signature by C over the keys only has = impact if C has already been added to the validators trust anchor set. Yup. >> Later in Section 2.2, it says: >>=20 >> In the given example, the zone owner can recover from a compromise = by >> revoking B and adding a new key D and signing the DNSKEY RRSet with >> both A and B. >>=20 >> The time progression here sounds like: >> 1: Owner's zone: A signs (A B) >> 2a: Attacker's zone: B signs (A Br C) >> 2b: Owner's zone: B signs (Br) and A signs (A D) and B signs (A D) >> 2a happens before 2b because that is how the owner discovers that B = was compromised. >=20 > What happens at a validator depends on what the validator sees. In = general this goes: >=20 > A Signs (A B) > B is compromised > Owner: A and B sign (A Br D) - B is revoked and D starts its process = of being added as a trust anchor. > Attacker: B signs (B C) >=20 > The key point is that if the validator sees even one of the "A and B = sign (A Br D)" RRSets, then B is revoked and "B signs (B C)" will fail = validation leading to C not being added to the trust anchor set. Yes, that's clearly the intent, and it should work (assuming that the = resolver follows the "revoke B as soon as you see a B-signed-Br = anywhere" rule). >> I don't understand why B signs (A D) in 2b. B is already untrusted to = anyone who saw 2a, and is untrusted by anyone looking at all of 2b. = These instructions seem to be saying "put a signature into the zone that = cannot be validated". I would think that 2b should just be "B signs (Br) = and A signs (A D)", but that's not what the RFC says. >=20 > You can't actually have two different versions of the DNSKEY RRSet = being simultaneously offered by a single responder. You *can* have = multiple signatures over a single DNSKEY RRSet. >=20 > So the above is actually "A and B sign (A Br D)". It's also actually = more like "A and B sign (Br D and Z)" where "Z" is one of the ZSKs. So = you get "B signs Br to revoke itself", "A signs D to add D to the trust = anchor set" and "A signs Z so that Z chains to the root of trust". =20 >=20 > That's expressed by a DNSKEY RRSet consisting of B with the revoke = bit, D with the SEP bit and Z without the SEP bit with two RRSIG(DNSKEY) = records consisting of a signature by A and a signature by B. On Oct 7, 2014, at 1:10 PM, Michael StJohns = wrote: > Sorry -=20 >=20 > This is actually "A and B sign (A Br D and Z)". >=20 > A signing key needs to be included in the DNSKEY RRSet even if its = already accepted as a trust anchor. That's mainly so the key id = reference of the RRSIG (DNSKEY) can find the appropriate public key for = validation.=20 Why D? Is it a replacement for B because 5011 works better with more = than one trust anchor? I didn't see anything in the section that = explained D, and from what you say above, it looks like I guessed wrong = the first time. --Paul Hoffman= From nobody Thu Oct 9 09:47:32 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F631A6FA3 for ; Thu, 9 Oct 2014 09:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_MID=0.497, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufXdqbo58urH for ; Thu, 9 Oct 2014 09:47:21 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CEB41AD291 for ; Thu, 9 Oct 2014 09:46:44 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-02v.sys.comcast.net with comcast id 14mZ1p00158ss0Y014mjYf; Thu, 09 Oct 2014 16:46:43 +0000 Received: from Mike-T530ssd.comcast.net ([69.255.115.150]) by resomta-po-14v.sys.comcast.net with comcast id 14mh1p00H3Em2Kp014mizk; Thu, 09 Oct 2014 16:46:43 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Oct 2014 12:46:57 -0400 To: Paul Hoffman From: Michael StJohns In-Reply-To: <51E89C93-5C03-4D02-B0FE-C1CBBC3ECA06@vpnc.org> References: <6767D274-D06D-4938-9126-7221ED7E3165@vpnc.org> <20141007200355.799B41A1A28@ietfa.amsl.com> <51E89C93-5C03-4D02-B0FE-C1CBBC3ECA06@vpnc.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_668046997==.ALT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412873203; bh=JwtwFx/JRb3n/TcxxRLnrsVLitoYuiu/OZch5rzD+RM=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=rIqlD5Y0WIHgxuKqeE6SAX+i29onTFVsbFqbX6pSrT2j1yAMCqZMlsxLFUIS6cHnZ dUyrhkD+GI1gql+y+DfdDcowWczPAEvV2tcH1S/Cjr/hXkEpEGayd1tgT+OJWRIHWZ Eew3N0NuZsvFPvOye6ao748QfpgSIbKfWV8DSbtMesFwvE1ONetkTK5VP/P7aHk4IY Fz9SRq31FNm/QailgUG2QeDCvpGHkXlorAEhqLUSfr2OeNOODLFN9NpqeRFmQxcOlE P73om5gbQrcQ7P2eYSJ42VCa5mrLm5unO4yVG7GmKDoL6Q8DJ6vp5hs7C9cOVeSoE5 MNFJkQJSGNYNw== Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/6J7B8dcRZ98in4E8S-SR2kGSg3k Cc: DNSEXT Group Working Subject: Re: [dnsext] How are people implementing hold-down in RFC 5011? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 16:47:26 -0000 --=====================_668046997==.ALT Content-Type: text/plain; charset="us-ascii" At 07:57 PM 10/7/2014, Paul Hoffman wrote: >Thanks for the clarifications. I still have a bunch of questions, and I really do wonder if implementers agree with your interpretations. > >On Oct 7, 2014, at 1:03 PM, Michael StJohns wrote: > >> At 01:13 PM 10/7/2014, Paul Hoffman wrote: >>> Greetings. In reading RFC 5011 more carefully, I am finding that some of the wording is confusing (possibly just to me). I have a few questions for people who have implemented it in systems, but also want to hear from the greater DNS community. >>> >>> Section 2.2 says: >>> >>> Assume two trust point keys A and B. Assume that B has been >>> compromised. An attacker could generate and add a new trust anchor >>> key C (by adding C to the DNSKEY RRSet and signing it with B), and >>> then invalidate the compromised key. This would result in both the >>> attacker and owner being able to sign data in the zone and have it >>> accepted as valid by resolvers. >>> >>> I am assuming that "invalidate" means "revoke". >> >> Yes. >> >>> Pictorially, I think this means the following progression in time: >>> 1: Owner's zone: A signs (A B) >>> >> >> 1.5 Attacker's zone: B signs (B C) >> (This has to happen for the Add Hold down time until C becomes a valid trust anchor. In general this is going to be B and C sign (B, C) for the hold down period). > >There is nothing in the quoted paragraph from the RFC that indicates that the attacker gets C to be a valid trust anchor. It sounds like you meant to say "the attack is only going to work if a relying party trust C, and that will only happen after the hold-down period, so the attacker first introduces C, then only that has succeeded for some desired targets, revokes B". The add hold down time is meant to provide some breathing room for the owner against an attacker adding a new trust anchor. If the attacker holds only one key (B), and the owner doesn't revoke it, then eventually the attacker can add a new trust anchor (C). The incantation for the attacker is "B and C sign (B C X)" where X is a ZSK key owned by the attacker. The moment that the owner sees something it hasn't itself signed, signed with B, then the owner should issue "A and B sign (A, Br, D, Z)" where D is the owner's replacement for B and where Z is a ZSK key owned by the owner. Any SEP key can become a trust anchor if it is validly signed and is in the DNSKEY RRSet for the add hold down time (plus one retrieval). >> >>> 2: Attacker's zone: B signs (A Br C) >>> (Here, "Br" means "B with the REVOKE bit set".) >> >> 2 is actually B and C sign (Br C). > >When the RFC says "and signing it with B", it might be clearer if it says "and signing it with B and C". It is far from clear which messages from the attacker are for public consumption (which would be seen by the zone owner) and which are meant for restricted relying parties. That's not actually a matter of concern for the zone owner. The incantation to revoke a key K is "K signs (Kr)". As I noted elsewhere, you can't actually have multiple disjoint DNSKEY RRSets for a given name, so that you end up doing a union of all the keys to be signed into a single DNSKEY RRSet and you provide signatures by all signers over all the keys. With respect to the relying party - he doesn't know and can't tell - who originated the DNSKEY and signature data he's seeing. It's a crap shoot as to which version of the "truth" (owner or attacker) he sees. The 5011 model is designed to make it as difficult as possible for an attacker to feed its version of truth to a specific validating resolver for a long enough period of time so that resolver installs a new trust anchor AND never sees the revocation of the compromised trust anchor. >>> Immediately after the relying party has seen (2), B can never be trusted again, even while they are waiting for the hold-down timer for adding C. >> >> Revocation takes place immediately. Once the bit is set and validly signed, the key is revoked and can't be used for anything except signing the revocation. So in B and C sign (Br C), the signature over the keys by B only has impact on Br, The signature by C over the keys only has impact if C has already been added to the validators trust anchor set. > >Yup. > >>> Later in Section 2.2, it says: >>> >>> In the given example, the zone owner can recover from a compromise by >>> revoking B and adding a new key D and signing the DNSKEY RRSet with >>> both A and B. >>> >>> The time progression here sounds like: >>> 1: Owner's zone: A signs (A B) >>> 2a: Attacker's zone: B signs (A Br C) >>> 2b: Owner's zone: B signs (Br) and A signs (A D) and B signs (A D) >>> 2a happens before 2b because that is how the owner discovers that B was compromised. >> >> What happens at a validator depends on what the validator sees. In general this goes: >> >> A Signs (A B) >> B is compromised >> Owner: A and B sign (A Br D) - B is revoked and D starts its process of being added as a trust anchor. >> Attacker: B signs (B C) >> >> The key point is that if the validator sees even one of the "A and B sign (A Br D)" RRSets, then B is revoked and "B signs (B C)" will fail validation leading to C not being added to the trust anchor set. > >Yes, that's clearly the intent, and it should work (assuming that the resolver follows the "revoke B as soon as you see a B-signed-Br anywhere" rule). I can't help it if they don't read the black and white text of 5011. > A key is considered revoked when the resolver sees the key in a > self-signed RRSet and the key has the REVOKE bit (see Section 7 > below) set to '1'. Once the resolver sees the REVOKE bit, it MUST > NOT use this key as a trust anchor or for any other purpose except to > validate the RRSIG it signed over the DNSKEY RRSet specifically for > the purpose of validating the revocation. Unlike the 'Add' operation > below, revocation is immediate and permanent upon receipt of a valid > revocation at the resolver. >>> I don't understand why B signs (A D) in 2b. B is already untrusted to anyone who saw 2a, and is untrusted by anyone looking at all of 2b. These instructions seem to be saying "put a signature into the zone that cannot be validated". I would think that 2b should just be "B signs (Br) and A signs (A D)", but that's not what the RFC says. >> >> You can't actually have two different versions of the DNSKEY RRSet being simultaneously offered by a single responder. You *can* have multiple signatures over a single DNSKEY RRSet. >> >> So the above is actually "A and B sign (A Br D)". It's also actually more like "A and B sign (Br D and Z)" where "Z" is one of the ZSKs. So you get "B signs Br to revoke itself", "A signs D to add D to the trust anchor set" and "A signs Z so that Z chains to the root of trust". >> >> That's expressed by a DNSKEY RRSet consisting of B with the revoke bit, D with the SEP bit and Z without the SEP bit with two RRSIG(DNSKEY) records consisting of a signature by A and a signature by B. > > >On Oct 7, 2014, at 1:10 PM, Michael StJohns wrote: > >> Sorry - >> >> This is actually "A and B sign (A Br D and Z)". >> >> A signing key needs to be included in the DNSKEY RRSet even if its already accepted as a trust anchor. That's mainly so the key id reference of the RRSIG (DNSKEY) can find the appropriate public key for validation. > >Why D? Is it a replacement for B because 5011 works better with more than one trust anchor? I didn't see anything in the section that explained D, and from what you say above, it looks like I guessed wrong the first time. Yes, D is the owner's replacement for B. I don't name the keys as "C" and "D" in section 6.1, but that's what's happening. You used "C" as the "Attacker's new trust anchor" in this series of messages. I probably would have used something more disjoint in the explanation. So to clarify. 1) Start with two trust anchors (A B) and a ZSK (Z) (let Z stand for any of the regularly generated ZSKs) 2) B is a stand by key - it's a trust anchor, but not used for regular quarterly signing 3) The normal DNSKEY RRSet is "A signs (A Z)" 4) If A or B is compromised then generate a new key pair C 5) Assuming A is compromised issue a new RRSET "A and B sign (Ar B C Z)" and propagate that for twice the add hold down time. (the add hold down time to get the bits set, the additional time to pick up stragglers - the additional time is just suspenders and belt) 6) Once you've done (5) for long enough, issue a new "normal" RRSET "B signs (B Z)". C is now a standby key. In practice, it may take a little time to get folks together for the key ceremony for C, so you may end up with an interim DNSKEY RRSet "A and B sign (Ar B Z)" for a few days. [Which by itself suggests a need to be able to do signatures without having everyone physically present] In the above, the attacker's only ploy is to do "A signs (A N X)" where N is a new trust anchor key owned by the attacker and X is a new ZSK also owned by the attacker. His hope is that the validly signed (by compromised key A) RRSet gets accepted for a short while by specific targets and maybe long enough to get a new trust anchor key accepted by those specific targets. >--Paul Hoffman --=====================_668046997==.ALT Content-Type: text/html; charset="us-ascii" At 07:57 PM 10/7/2014, Paul Hoffman wrote:
Thanks for the clarifications. I still have a bunch of questions, and I really do wonder if implementers agree with your interpretations.

On Oct 7, 2014, at 1:03 PM, Michael StJohns <mstjohns@comcast.net> wrote:

> At 01:13 PM 10/7/2014, Paul Hoffman wrote:
>> Greetings. In reading RFC 5011 more carefully, I am finding that some of the wording is confusing (possibly just to me). I have a few questions for people who have implemented it in systems, but also want to hear from the greater DNS community.
>>
>> Section 2.2 says:
>>
>>  Assume two trust point keys A and B.  Assume that B has been
>>  compromised.  An attacker could generate and add a new trust anchor
>>  key C (by adding C to the DNSKEY RRSet and signing it with B), and
>>  then invalidate the compromised key.  This would result in both the
>>  attacker and owner being able to sign data in the zone and have it
>>  accepted as valid by resolvers.
>>
>> I am assuming that "invalidate" means "revoke".
>
> Yes. 
>
>> Pictorially, I think this means the following progression in time:
>>  1: Owner's zone: A signs (A B)
>>
>
> 1.5 Attacker's zone: B signs (B C)
> (This has to happen for the Add Hold down time until C becomes a valid trust anchor.  In general this is going to be B and C sign (B, C) for the hold down period).

There is nothing in the quoted paragraph from the RFC that indicates that the attacker gets C to be a valid trust anchor. It sounds like you meant to say "the attack is only going to work if a relying party trust C, and that will only happen after the hold-down period, so the attacker first introduces C, then only that has succeeded for some desired targets, revokes B".


The add hold down time is meant to provide some breathing room for the owner against an attacker adding a new trust anchor.  If the attacker holds only one key (B), and the owner doesn't revoke it, then eventually the attacker can add a new trust anchor (C).  The incantation for the attacker is "B and C sign (B C X)" where X is a ZSK key owned by the attacker.   The moment that the owner sees something it hasn't itself signed, signed with B, then the owner should issue "A and B sign (A, Br, D, Z)" where D is the owner's replacement for B and where Z is a ZSK key owned by the owner.

Any SEP key can become a trust anchor if it is validly signed and is in the DNSKEY RRSet for the add hold down time (plus one retrieval).




>
>> 2: Attacker's zone: B signs (A Br C)
>> (Here, "Br" means "B with the REVOKE bit set".)
>
> 2 is actually B and C sign (Br C).

When the RFC says "and signing it with B", it might be clearer if it says "and signing it with B and C". It is far from clear which messages from the attacker are for public consumption (which would be seen by the zone owner) and which are meant for restricted relying parties.

That's not actually a matter of concern for the zone owner.   The incantation to revoke a key K is "K signs (Kr)".  As I noted elsewhere, you can't actually have multiple disjoint DNSKEY RRSets for a given name, so that you end up doing a union of all the keys to be signed into a single DNSKEY RRSet and you provide signatures by all signers over all the keys.

With respect to the relying party - he doesn't know and can't tell - who originated the DNSKEY and signature data he's seeing.  It's a crap shoot as to which version of the "truth" (owner or attacker) he sees.  The 5011 model is designed to make it as difficult as possible for an attacker to feed its version of truth to a specific validating resolver for a long enough period of time so that resolver installs a new trust anchor AND never sees the revocation of the compromised trust anchor.


>> Immediately after the relying party has seen (2), B can never be trusted again, even while they are waiting for the hold-down timer for adding C.
>
> Revocation takes place immediately.  Once the bit is set and validly signed, the key is revoked and can't be used for anything except signing the revocation.  So in B and C sign (Br C), the signature over the keys by B only has impact on Br,  The signature by C over the keys only has impact if C has already been added to the validators trust anchor set.

Yup.

>> Later in Section 2.2, it says:
>>
>>  In the given example, the zone owner can recover from a compromise by
>>  revoking B and adding a new key D and signing the DNSKEY RRSet with
>>  both A and B.
>>
>> The time progression here sounds like:
>>  1: Owner's zone: A signs (A B)
>>  2a: Attacker's zone: B signs (A Br C)
>>  2b: Owner's zone: B signs (Br) and A signs (A D) and B signs (A D)
>> 2a happens before 2b because that is how the owner discovers that B was compromised.
>
> What happens at a validator depends on what the validator sees.  In general this goes:
>
> A Signs (A B)
> B is compromised
> Owner:  A and B sign (A Br D) - B is revoked and D starts its process of being added as a trust anchor.
> Attacker:  B signs (B C)
>
> The key point is that if the validator sees even one of the "A and B sign (A Br D)" RRSets, then B is revoked and "B signs (B C)" will fail validation leading to C not being added to the trust anchor set.

Yes, that's clearly the intent, and it should work (assuming that the resolver follows the "revoke B as soon as you see a B-signed-Br anywhere" rule).


I can't help it if they don't read the black and white text of 5011.  



   A key is
considered revoked when the resolver sees the key in a
   self-signed RRSet and the key has the REVOKE bit (see
Section 7
   below) set to '1'.  Once the resolver sees the REVOKE
bit, it MUST
   NOT use this key as a trust anchor or for any other purpose
except to
   validate the RRSIG it signed over the DNSKEY RRSet
specifically for
   the purpose of validating the revocation.  Unlike the
'Add' operation
   below, revocation is immediate and permanent upon receipt of
a valid
   revocation at the
resolver.



>> I don't understand why B signs (A D) in 2b. B is already untrusted to anyone who saw 2a, and is untrusted by anyone looking at all of 2b. These instructions seem to be saying "put a signature into the zone that cannot be validated". I would think that 2b should just be "B signs (Br) and A signs (A D)", but that's not what the RFC says.
>
> You can't actually have two different versions of the DNSKEY RRSet being simultaneously offered by a single responder.  You *can* have multiple signatures over a single DNSKEY RRSet.
>
> So the above is actually "A and B sign (A Br D)".  It's also actually more like "A and B sign (Br D and Z)" where "Z" is one of the ZSKs.  So you get "B signs Br to revoke itself", "A signs D to add D to the trust anchor set" and "A signs Z so that Z chains to the root of trust". 
>
> That's expressed by a DNSKEY RRSet consisting of B with the revoke bit, D with the SEP bit and Z without the SEP bit with two RRSIG(DNSKEY) records consisting of a signature by A and  a signature by B.


On Oct 7, 2014, at 1:10 PM, Michael StJohns <mstjohns@comcast.net> wrote:

> Sorry -
>
> This is actually "A and B sign (A Br D and Z)".
>
> A signing key needs to be included in the DNSKEY RRSet even if its already accepted as a trust anchor.  That's mainly so the key id reference of the RRSIG (DNSKEY) can find the appropriate public key for validation.

Why D? Is it a replacement for B because 5011 works better with more than one trust anchor? I didn't see anything in the section that explained D, and from what you say above, it looks like I guessed wrong the first time.


Yes, D is the owner's replacement for B.    I don't name the keys as "C" and "D" in section 6.1, but that's what's happening.

You used "C" as the "Attacker's new trust anchor" in this series of messages.  I probably would have used something more disjoint in the explanation.


So to clarify.

1) Start with two trust anchors (A B) and a ZSK (Z) (let Z stand for any of the regularly generated ZSKs)
2) B is a stand by key - it's a trust anchor, but not used for regular quarterly signing
3) The normal DNSKEY RRSet is "A signs (A Z)"
4) If A or B is compromised then generate a new key pair C
5) Assuming A is compromised issue a new RRSET  "A and B sign (Ar B C Z)"  and propagate that for twice the add hold down time.  (the add hold down time to get the bits set, the additional time to pick up stragglers - the additional time is just suspenders and belt)
6) Once you've done (5) for long enough, issue a new "normal" RRSET "B signs (B Z)".  C is now a standby key.


In practice, it may take a little time to get folks together for the key ceremony for C, so you may end up with an interim DNSKEY RRSet "A and B sign (Ar B Z)" for a few days.  [Which by itself suggests a need to be able to do signatures without having everyone physically present]


In the above, the attacker's only ploy is to do "A signs (A N X)" where N is a new trust anchor key owned by the attacker and X is a new ZSK also owned by the attacker.  His hope is that the validly signed (by compromised key A) RRSet gets accepted for a short while by specific targets and maybe long enough to get a new trust anchor key accepted by those specific targets.


--Paul Hoffman

--=====================_668046997==.ALT-- From nobody Mon Oct 13 02:00:01 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9DB1A6FC7 for ; Mon, 13 Oct 2014 02:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYRhLJ4vcHlC for ; Mon, 13 Oct 2014 01:59:57 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B931A6F12 for ; Mon, 13 Oct 2014 01:59:56 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id em10so6748781wid.10 for ; Mon, 13 Oct 2014 01:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xjy6MKPRAK82oDDk+RN1COrUWnSlW3ddGqyBNCB+XXo=; b=qE0QRBpoqFFVqsFa9b8bm311VMWAS1kc5b+Fn6ibKJm1ic05vjD2esZlRvkERBwBBk LxwTvtSQr04OYhnFJFuh9NBRmgJnTe729uy7AShK+fmgF3ooEEGaH9p5jxXCbn+KiP6S +udQffWc1NRPbUmNZAWh55sleW6j2yPvvGtew= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xjy6MKPRAK82oDDk+RN1COrUWnSlW3ddGqyBNCB+XXo=; b=TFYdsUR3nHe8y50ny+qqxQk1a9De/M87Jm//rH4a97AdD3RN7zD17dMWoT778FtzhZ kHpkVLWK1ragkdnWmPvYZ6vy7q1BvkhOS/NN19ehNYyKbI6gmReVuzf975mZqBqfLPeD jUWlXy5LXE55+JTDeTOetlKM/kmPASFyKvh34dGOMnP4U0cA2iZZHHaucM0VojieCgyO zif23re3ABxRTKg/nUDcsOyxheNAeg8BKxzX+jduxJbY816p0rPLjnQSa3sGSoUPojGi z9Q+9lLLl5JNnYmG7ZfoqgkClu5CCilwpHNlX7PC9I2Pu09YgaGoSX0VuqrUr3OMxCcp DdTA== X-Gm-Message-State: ALoCoQn8+HTLJA/IpGpKjct95BdSgJ2swp1aGDiQCNKfkEoFxCSxXdp3cizY/de7dgzt2RGXe3o8 X-Received: by 10.194.21.193 with SMTP id x1mr517499wje.135.1413190795751; Mon, 13 Oct 2014 01:59:55 -0700 (PDT) Received: from ?IPv6:2001:981:19be:1:5083:6662:12ad:6086? ([2001:981:19be:1:5083:6662:12ad:6086]) by mx.google.com with ESMTPSA id q3sm11413703wia.14.2014.10.13.01.59.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Oct 2014 01:59:55 -0700 (PDT) Message-ID: <543B948A.3010903@dyn.com> Date: Mon, 13 Oct 2014 10:59:54 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Michael StJohns , Paul Hoffman References: <6767D274-D06D-4938-9126-7221ED7E3165@vpnc.org> <20141007200355.799B41A1A28@ietfa.amsl.com> <51E89C93-5C03-4D02-B0FE-C1CBBC3ECA06@vpnc.org> <20141009164731.E51F71AD272@ietfa.amsl.com> In-Reply-To: <20141009164731.E51F71AD272@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/e5QUTEOtbsj7Va-OKdv2AjGOAIc Cc: DNSEXT Group Working Subject: Re: [dnsext] How are people implementing hold-down in RFC 5011? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 09:00:00 -0000 Hi, On 09-10-14 18:46, Michael StJohns wrote: > At 07:57 PM 10/7/2014, Paul Hoffman wrote: >> Thanks for the clarifications. I still have a bunch of questions, and >> I really do wonder if implementers agree with your interpretations. I have implemented this (http://nlnetlabs.nl/projects/autotrust/) and I agree with Michael's interpretations (even if it was after an hour asking questions at some past IETF). I am trying to clarify below, although most stuff seems already straighted out. >> On Oct 7, 2014, at 1:03 PM, Michael StJohns wrote: >> >> > At 01:13 PM 10/7/2014, Paul Hoffman wrote: >> >> Greetings. In reading RFC 5011 more carefully, I am finding that >> some of the wording is confusing (possibly just to me). I have a few >> questions for people who have implemented it in systems, but also want >> to hear from the greater DNS community. >> >> >> >> Section 2.2 says: >> >> >> >> Assume two trust point keys A and B. Assume that B has been >> >> compromised. An attacker could generate and add a new trust anchor >> >> key C (by adding C to the DNSKEY RRSet and signing it with B), and >> >> then invalidate the compromised key. This would result in both the >> >> attacker and owner being able to sign data in the zone and have it >> >> accepted as valid by resolvers. >> >> >> >> I am assuming that "invalidate" means "revoke". >> > >> > Yes. >> > >> >> Pictorially, I think this means the following progression in time: >> >> 1: Owner's zone: A signs (A B) >> >> >> > >> > 1.5 Attacker's zone: B signs (B C) >> > (This has to happen for the Add Hold down time until C becomes a >> valid trust anchor. In general this is going to be B and C sign (B, >> C) for the hold down period). >> >> There is nothing in the quoted paragraph from the RFC that indicates >> that the attacker gets C to be a valid trust anchor. It sounds like >> you meant to say "the attack is only going to work if a relying party >> trust C, and that will only happen after the hold-down period, so the >> attacker first introduces C, then only that has succeeded for some >> desired targets, revokes B". > > > The add hold down time is meant to provide some breathing room for the > owner against an attacker adding a new trust anchor. If the attacker > holds only one key (B), and the owner doesn't revoke it, then eventually > the attacker can add a new trust anchor (C). The incantation for the > attacker is "B and C sign (B C X)" where X is a ZSK key owned by the > attacker. The moment that the owner sees something it hasn't itself > signed, signed with B, then the owner should issue "A and B sign (A, Br, > D, Z)" where D is the owner's replacement for B and where Z is a ZSK key > owned by the owner. > > Any SEP key can become a trust anchor if it is validly signed and is in > the DNSKEY RRSet for the add hold down time (plus one retrieval). All above seems pretty clear. >> > >> >> 2: Attacker's zone: B signs (A Br C) >> >> (Here, "Br" means "B with the REVOKE bit set".) >> > >> > 2 is actually B and C sign (Br C). >> >> When the RFC says "and signing it with B", it might be clearer if it >> says "and signing it with B and C". It is far from clear which >> messages from the attacker are for public consumption (which would be >> seen by the zone owner) and which are meant for restricted relying >> parties. > > That's not actually a matter of concern for the zone owner. The > incantation to revoke a key K is "K signs (Kr)". As I noted elsewhere, > you can't actually have multiple disjoint DNSKEY RRSets for a given > name, so that you end up doing a union of all the keys to be signed into > a single DNSKEY RRSet and you provide signatures by all signers over all > the keys. When the RFC says "and signing it with B" in section 2.2 Add Hold-Down, it talks about adding C to the DNSKEY RRset. C is still a stand-by key and does not necessarily need to sign the DNSKEY set. C will still be added to the validator in the AddPend state. When B is revoked, you do want to sign with both B and C: B to self-sign (Br) and C to sign the DNSKEY RRset. > With respect to the relying party - he doesn't know and can't tell - who > originated the DNSKEY and signature data he's seeing. It's a crap shoot > as to which version of the "truth" (owner or attacker) he sees. The > 5011 model is designed to make it as difficult as possible for an > attacker to feed its version of truth to a specific validating resolver > for a long enough period of time so that resolver installs a new trust > anchor AND never sees the revocation of the compromised trust anchor. > > >> >> Immediately after the relying party has seen (2), B can never be >> trusted again, even while they are waiting for the hold-down timer for >> adding C. >> > >> > Revocation takes place immediately. Once the bit is set and validly >> signed, the key is revoked and can't be used for anything except >> signing the revocation. So in B and C sign (Br C), the signature over >> the keys by B only has impact on Br, The signature by C over the keys >> only has impact if C has already been added to the validators trust >> anchor set. >> >> Yup. >> >> >> Later in Section 2.2, it says: >> >> >> >> In the given example, the zone owner can recover from a compromise by >> >> revoking B and adding a new key D and signing the DNSKEY RRSet with >> >> both A and B. >> >> >> >> The time progression here sounds like: >> >> 1: Owner's zone: A signs (A B) >> >> 2a: Attacker's zone: B signs (A Br C) >> >> 2b: Owner's zone: B signs (Br) and A signs (A D) and B signs (A D) >> >> 2a happens before 2b because that is how the owner discovers that B >> was compromised. I think the time progression is as follows: 1a: Owner's zone: A signs (A B) 1b: Attacker's zone: B signs (B C) 2a: Owner's zone: A and B signs (A Br D) 2b: Attacker's zone: B and C signs (Br C) The owner should do step 2a before the attacker is able to do 2b. >> > >> > What happens at a validator depends on what the validator sees. In >> general this goes: >> > >> > A Signs (A B) >> > B is compromised >> > Owner: A and B sign (A Br D) - B is revoked and D starts its >> process of being added as a trust anchor. >> > Attacker: B signs (B C) >> > >> > The key point is that if the validator sees even one of the "A and B >> sign (A Br D)" RRSets, then B is revoked and "B signs (B C)" will fail >> validation leading to C not being added to the trust anchor set. >> >> Yes, that's clearly the intent, and it should work (assuming that the >> resolver follows the "revoke B as soon as you see a B-signed-Br >> anywhere" rule). > > > I can't help it if they don't read the black and white text of 5011. > > > >> A key is >> considered revoked when the resolver sees the key in a >> self-signed RRSet and the key has the REVOKE bit (see >> Section 7 >> below) set to '1'. Once the resolver sees the REVOKE >> bit, it MUST >> NOT use this key as a trust anchor or for any other purpose >> except to >> validate the RRSIG it signed over the DNSKEY RRSet >> specifically for >> the purpose of validating the revocation. Unlike the >> 'Add' operation >> below, revocation is immediate and permanent upon receipt of >> a valid >> revocation at the >> resolver. > > > >> >> I don't understand why B signs (A D) in 2b. B is already untrusted >> to anyone who saw 2a, and is untrusted by anyone looking at all of 2b. >> These instructions seem to be saying "put a signature into the zone >> that cannot be validated". I would think that 2b should just be "B >> signs (Br) and A signs (A D)", but that's not what the RFC says. >> > >> > You can't actually have two different versions of the DNSKEY RRSet >> being simultaneously offered by a single responder. You *can* have >> multiple signatures over a single DNSKEY RRSet. >> > >> > So the above is actually "A and B sign (A Br D)". It's also actually >> more like "A and B sign (Br D and Z)" where "Z" is one of the ZSKs. >> So you get "B signs Br to revoke itself", "A signs D to add D to the >> trust anchor set" and "A signs Z so that Z chains to the root of trust". >> > >> > That's expressed by a DNSKEY RRSet consisting of B with the revoke >> bit, D with the SEP bit and Z without the SEP bit with two >> RRSIG(DNSKEY) records consisting of a signature by A and a signature >> by B. >> >> >> On Oct 7, 2014, at 1:10 PM, Michael StJohns wrote: >> >> > Sorry - >> > >> > This is actually "A and B sign (A Br D and Z)". >> > >> > A signing key needs to be included in the DNSKEY RRSet even if its >> already accepted as a trust anchor. That's mainly so the key id >> reference of the RRSIG (DNSKEY) can find the appropriate public key >> for validation. >> >> Why D? Is it a replacement for B because 5011 works better with more >> than one trust anchor? I didn't see anything in the section that >> explained D, and from what you say above, it looks like I guessed >> wrong the first time. > > > Yes, D is the owner's replacement for B. I don't name the keys as "C" > and "D" in section 6.1, but that's what's happening. > > You used "C" as the "Attacker's new trust anchor" in this series of > messages. I probably would have used something more disjoint in the > explanation. > > > So to clarify. > > 1) Start with two trust anchors (A B) and a ZSK (Z) (let Z stand for any > of the regularly generated ZSKs) > 2) B is a stand by key - it's a trust anchor, but not used for regular > quarterly signing > 3) The normal DNSKEY RRSet is "A signs (A Z)" Since B is a standby key, it should be "A signs (A B Z)" > 4) If A or B is compromised then generate a new key pair C > 5) Assuming A is compromised issue a new RRSET "A and B sign (Ar B C > Z)" and propagate that for twice the add hold down time. (the add hold > down time to get the bits set, the additional time to pick up stragglers > - the additional time is just suspenders and belt) > 6) Once you've done (5) for long enough, issue a new "normal" RRSET "B > signs (B Z)". C is now a standby key. 6) should be "B signs (B C Z)". Best regards, Matthijs > In practice, it may take a little time to get folks together for the key > ceremony for C, so you may end up with an interim DNSKEY RRSet "A and B > sign (Ar B Z)" for a few days. [Which by itself suggests a need to be > able to do signatures without having everyone physically present] > > > In the above, the attacker's only ploy is to do "A signs (A N X)" where > N is a new trust anchor key owned by the attacker and X is a new ZSK > also owned by the attacker. His hope is that the validly signed (by > compromised key A) RRSet gets accepted for a short while by specific > targets and maybe long enough to get a new trust anchor key accepted by > those specific targets. > > >> --Paul Hoffman > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From nobody Mon Oct 13 08:58:15 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6556C1A0346 for ; Mon, 13 Oct 2014 08:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MISSING_MID=0.497, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6ci-yH_AsbX for ; Mon, 13 Oct 2014 08:58:09 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27851A037D for ; Mon, 13 Oct 2014 08:58:07 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-11v.sys.comcast.net with comcast id 2fuq1p00552QWKC01fy7dE; Mon, 13 Oct 2014 15:58:07 +0000 Received: from Mike-T530ssd.comcast.net ([69.255.115.150]) by resomta-po-09v.sys.comcast.net with comcast id 2fy61p0023Em2Kp01fy6p4; Mon, 13 Oct 2014 15:58:07 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Oct 2014 11:58:26 -0400 To: Matthijs Mekking ,Paul Hoffman From: Michael StJohns In-Reply-To: <543B948A.3010903@dyn.com> References: <6767D274-D06D-4938-9126-7221ED7E3165@vpnc.org> <20141007200355.799B41A1A28@ietfa.amsl.com> <51E89C93-5C03-4D02-B0FE-C1CBBC3ECA06@vpnc.org> <20141009164731.E51F71AD272@ietfa.amsl.com> <543B948A.3010903@dyn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413215887; bh=sAFRTosh1K2lpVRtxpgBrHKp0vfM6b0A7cKLtci5xP4=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=EZT9Ich/YnQfruCw+AU76OJpD6FGSxxZwYSr2ziuuAFUBEE8Nw10rMzeHPc2Y3Zup k1uWUxe33RT2pZ/JaSf1hZHEyfxbE4AZy/efiszGccb3tvyvV6LnoePZaBl1B7YTBq 2h2OHG/vbf8QiconZAR9PjHwpFsGSQc30L6fnt1s6F1lqvS9+YL39ZDId0hY65nKbY wpnhd1mQY8Ks84lXh5Jf/Suhkm0niZGDZ8fVOuR8NXPaEy9fr2zvpV2CALXm6weP3f a5uPz0TbO/+UDJMubbvv2Xlt1XC2sWF5K056mKDOzhTpV8J6c/97smOP6egYNzePxY Hf5nKBRMaNTLw== Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/HPeispLRn8nx-Ww1J5WupSyKYCg Cc: DNSEXT Group Working Subject: Re: [dnsext] How are people implementing hold-down in RFC 5011? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:58:11 -0000 At 04:59 AM 10/13/2014, Matthijs Mekking wrote: >Hi, > >On 09-10-14 18:46, Michael StJohns wrote: >>At 07:57 PM 10/7/2014, Paul Hoffman wrote: >>>Thanks for the clarifications. I still have a bunch of questions, and >>>I really do wonder if implementers agree with your interpretations. > > >>>> >>>>> 2: Attacker's zone: B signs (A Br C) >>>>> (Here, "Br" means "B with the REVOKE bit set".) >>>> >>>> 2 is actually B and C sign (Br C). >>> >>>When the RFC says "and signing it with B", it might be clearer if it >>>says "and signing it with B and C". It is far from clear which >>>messages from the attacker are for public consumption (which would be >>>seen by the zone owner) and which are meant for restricted relying >>>parties. >> >>That's not actually a matter of concern for the zone owner. The >>incantation to revoke a key K is "K signs (Kr)". As I noted elsewhere, >>you can't actually have multiple disjoint DNSKEY RRSets for a given >>name, so that you end up doing a union of all the keys to be signed into >>a single DNSKEY RRSet and you provide signatures by all signers over all >>the keys. > >When the RFC says "and signing it with B" in section 2.2 Add Hold-Down, it talks about adding C to the DNSKEY RRset. C is still a stand-by key and does not necessarily need to sign the DNSKEY set. C will still be added to the validator in the AddPend state. > >When B is revoked, you do want to sign with both B and C: B to self-sign (Br) and C to sign the DNSKEY RRset. It depends. If A is still sacrosanct - then the usual incantation for the owner will be "A and B sign (A Br C Z)" where C is a new trust anchor and Z is the ZSK. C becomes a standby trust anchor and doesn't have to actually sign the root DNSKEY RRSet until it's placed into active service. For the attacker, trying to add a new trust anchor that he owns (N), the incantation is going to be "B and N sign (B N X)" where X is a ZSK owned by the attacker. The attacker - if all he holds is B - can't sign Br until after the Add Holddown period expires if he's trying to add a new attacker owned trust anchor. >>With respect to the relying party - he doesn't know and can't tell - who >>originated the DNSKEY and signature data he's seeing. It's a crap shoot >>as to which version of the "truth" (owner or attacker) he sees. The >>5011 model is designed to make it as difficult as possible for an >>attacker to feed its version of truth to a specific validating resolver >>for a long enough period of time so that resolver installs a new trust >>anchor AND never sees the revocation of the compromised trust anchor. >> >> >>>>> Immediately after the relying party has seen (2), B can never be >>>trusted again, even while they are waiting for the hold-down timer for >>>adding C. >>>> >>>> Revocation takes place immediately. Once the bit is set and validly >>>signed, the key is revoked and can't be used for anything except >>>signing the revocation. So in B and C sign (Br C), the signature over >>>the keys by B only has impact on Br, The signature by C over the keys >>>only has impact if C has already been added to the validators trust >>>anchor set. >>> >>>Yup. >>> >>>>> Later in Section 2.2, it says: >>>>> >>>>> In the given example, the zone owner can recover from a compromise by >>>>> revoking B and adding a new key D and signing the DNSKEY RRSet with >>>>> both A and B. >>>>> >>>>> The time progression here sounds like: >>>>> 1: Owner's zone: A signs (A B) >>>>> 2a: Attacker's zone: B signs (A Br C) >>>>> 2b: Owner's zone: B signs (Br) and A signs (A D) and B signs (A D) >>>>> 2a happens before 2b because that is how the owner discovers that B >>>was compromised. > >I think the time progression is as follows: > >1a: Owner's zone: A signs (A B) >1b: Attacker's zone: B signs (B C) >2a: Owner's zone: A and B signs (A Br D) >2b: Attacker's zone: B and C signs (Br C) > >The owner should do step 2a before the attacker is able to do 2b. Right, but 2a can happen as soon as the owner notices something hinky with the zone or suspects a compromise. 2b can't happen until 1b has been out in the wild for the entire Add Holddown time otherwise the attacker is throwing away its only mechanism for installing new trust anchors. >>Yes, D is the owner's replacement for B. I don't name the keys as "C" >>and "D" in section 6.1, but that's what's happening. >> >>You used "C" as the "Attacker's new trust anchor" in this series of >>messages. I probably would have used something more disjoint in the >>explanation. >> >> >>So to clarify. >> >>1) Start with two trust anchors (A B) and a ZSK (Z) (let Z stand for any >>of the regularly generated ZSKs) >>2) B is a stand by key - it's a trust anchor, but not used for regular >>quarterly signing >>3) The normal DNSKEY RRSet is "A signs (A Z)" > >Since B is a standby key, it should be "A signs (A B Z)" No. Once B is added as a trust anchor, it need not be included in the root DNSKEY RRSet. If B is not signing anything, there is no reason to include it. >>4) If A or B is compromised then generate a new key pair C >>5) Assuming A is compromised issue a new RRSET "A and B sign (Ar B C >>Z)" and propagate that for twice the add hold down time. (the add hold >>down time to get the bits set, the additional time to pick up stragglers >>- the additional time is just suspenders and belt) >>6) Once you've done (5) for long enough, issue a new "normal" RRSET "B >>signs (B Z)". C is now a standby key. > >6) should be "B signs (B C Z)". Same thing as above. Once C is a trust anchor, unless its actively signing something, there's no need to include it in the DNSKEY RRSet. [However, you increase the "take" rate for resolvers the longer you leave it there - especially if there are intermittently connected resolvers] Keys enter the trust anchor set only by being present in the root DNSKEY RRSet and signed by a previous trust anchor for a minimum period of time (the Add Hold Down). Keys leave the trust anchor set only through revocation. Mike >Best regards, > Matthijs From nobody Tue Oct 14 01:50:03 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7ACC1A6FD6 for ; Tue, 14 Oct 2014 01:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFRw6Q7FTc2S for ; Tue, 14 Oct 2014 01:49:59 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7B41A00F0 for ; Tue, 14 Oct 2014 01:49:59 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id h11so6042983wiw.5 for ; Tue, 14 Oct 2014 01:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=33ceqbTvV0wlxpzP5nXSSbFTd/3oPAkxkYlMgf//sSs=; b=G1Yw6Fw6YLJszfXWYZTNVUckmSndB2v7U1HmnBb0AsknKIhj6VEDLt4Lx6l4ViKgoM J5j8SwXdBxLAJy0ckB8/LDTA4Ofs8DoMxlSW6eiFZi0YQ9dwv3vccQPuE28CW06POkRT 8bY+MouG0gN/gzvDoIQxiVjJlGVn8yFmovCls= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=33ceqbTvV0wlxpzP5nXSSbFTd/3oPAkxkYlMgf//sSs=; b=gDx7T8ZdZF+84XPRqmgVt5nthTKiNDVXu+S+C+Y/MasAGiw3Sc7l6gdOb4X00ZXZfd ilPdQqSv7+ZlLeAuuRTZGnlivHOH98lInZnEdNvTt4PoOS4wc/TLwGWU86cigSu22LgY dSb7cNPZKIHRyoufQSrYdMjn3Ykzaqh4VM3sWmFqSS6EAmVfMYtoi0HRGzFD1W1WAoBf e4rPNqSC4GwIN4644l/g4Np80oZIiTfDyHGm//LI9zveSXrTRbKiGC+kDeeqBdk3rkTV 7Dphx2y8NaX44JY65pKUlyEO5pv9iz/zMSc9GytzQo7od1UTkCguoJaGrtTcmM9PrKkt HaAg== X-Gm-Message-State: ALoCoQkN9izCNrIr6AuFE6ARXjFvjHiAWNAGtsEK9AHra+VMWJYwmojLusj0M7PZyjMHL2oo3GGN X-Received: by 10.194.109.226 with SMTP id hv2mr3598460wjb.45.1413276597817; Tue, 14 Oct 2014 01:49:57 -0700 (PDT) Received: from ?IPv6:2001:981:19be:1:580a:9d7c:abc3:a246? ([2001:981:19be:1:580a:9d7c:abc3:a246]) by mx.google.com with ESMTPSA id hc8sm18053434wib.1.2014.10.14.01.49.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Oct 2014 01:49:57 -0700 (PDT) Message-ID: <543CE3B4.3000504@dyn.com> Date: Tue, 14 Oct 2014 10:49:56 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Michael StJohns , Paul Hoffman References: <6767D274-D06D-4938-9126-7221ED7E3165@vpnc.org> <20141007200355.799B41A1A28@ietfa.amsl.com> <51E89C93-5C03-4D02-B0FE-C1CBBC3ECA06@vpnc.org> <20141009164731.E51F71AD272@ietfa.amsl.com> <543B948A.3010903@dyn.com> <543bf690.c1e22a0a.1a1a.ffff89b7SMTPIN_ADDED_MISSING@mx.google.com> In-Reply-To: <543bf690.c1e22a0a.1a1a.ffff89b7SMTPIN_ADDED_MISSING@mx.google.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/mgMGfHrpgLBvWANmBEYnFSsEWb0 Cc: DNSEXT Group Working Subject: Re: [dnsext] How are people implementing hold-down in RFC 5011? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 08:50:01 -0000 On 13-10-14 17:58, Michael StJohns wrote: > At 04:59 AM 10/13/2014, Matthijs Mekking wrote: >> Hi, >> >> On 09-10-14 18:46, Michael StJohns wrote: >>> At 07:57 PM 10/7/2014, Paul Hoffman wrote: >>>> Thanks for the clarifications. I still have a bunch of >>>> questions, and I really do wonder if implementers agree with >>>> your interpretations. >> >> >>>>> >>>>>> 2: Attacker's zone: B signs (A Br C) (Here, "Br" means "B >>>>>> with the REVOKE bit set".) >>>>> >>>>> 2 is actually B and C sign (Br C). >>>> >>>> When the RFC says "and signing it with B", it might be clearer >>>> if it says "and signing it with B and C". It is far from clear >>>> which messages from the attacker are for public consumption >>>> (which would be seen by the zone owner) and which are meant for >>>> restricted relying parties. >>> >>> That's not actually a matter of concern for the zone owner. The >>> incantation to revoke a key K is "K signs (Kr)". As I noted >>> elsewhere, you can't actually have multiple disjoint DNSKEY >>> RRSets for a given name, so that you end up doing a union of all >>> the keys to be signed into a single DNSKEY RRSet and you provide >>> signatures by all signers over all the keys. >> >> When the RFC says "and signing it with B" in section 2.2 Add >> Hold-Down, it talks about adding C to the DNSKEY RRset. C is still >> a stand-by key and does not necessarily need to sign the DNSKEY >> set. C will still be added to the validator in the AddPend state. >> >> When B is revoked, you do want to sign with both B and C: B to >> self-sign (Br) and C to sign the DNSKEY RRset. > > It depends. If A is still sacrosanct - then the usual incantation > for the owner will be "A and B sign (A Br C Z)" where C is a new > trust anchor and Z is the ZSK. C becomes a standby trust anchor > and doesn't have to actually sign the root DNSKEY RRSet until it's > placed into active service. The scenario above is for the attacker, he has no incentive of keep publishing A. > For the attacker, trying to add a new trust anchor that he owns (N), > the incantation is going to be "B and N sign (B N X)" where X is a > ZSK owned by the attacker. > > The attacker - if all he holds is B - can't sign Br until after the > Add Holddown period expires if he's trying to add a new attacker > owned trust anchor. > > > >>> With respect to the relying party - he doesn't know and can't >>> tell - who originated the DNSKEY and signature data he's seeing. >>> It's a crap shoot as to which version of the "truth" (owner or >>> attacker) he sees. The 5011 model is designed to make it as >>> difficult as possible for an attacker to feed its version of >>> truth to a specific validating resolver for a long enough period >>> of time so that resolver installs a new trust anchor AND never >>> sees the revocation of the compromised trust anchor. >>> >>> >>>>>> Immediately after the relying party has seen (2), B can >>>>>> never be >>>> trusted again, even while they are waiting for the hold-down >>>> timer for adding C. >>>>> >>>>> Revocation takes place immediately. Once the bit is set and >>>>> validly >>>> signed, the key is revoked and can't be used for anything >>>> except signing the revocation. So in B and C sign (Br C), the >>>> signature over the keys by B only has impact on Br, The >>>> signature by C over the keys only has impact if C has already >>>> been added to the validators trust anchor set. >>>> >>>> Yup. >>>> >>>>>> Later in Section 2.2, it says: >>>>>> >>>>>> In the given example, the zone owner can recover from a >>>>>> compromise by revoking B and adding a new key D and signing >>>>>> the DNSKEY RRSet with both A and B. >>>>>> >>>>>> The time progression here sounds like: 1: Owner's zone: A >>>>>> signs (A B) 2a: Attacker's zone: B signs (A Br C) 2b: >>>>>> Owner's zone: B signs (Br) and A signs (A D) and B signs (A >>>>>> D) 2a happens before 2b because that is how the owner >>>>>> discovers that B >>>> was compromised. >> >> I think the time progression is as follows: >> >> 1a: Owner's zone: A signs (A B) 1b: Attacker's zone: B signs (B >> C) 2a: Owner's zone: A and B signs (A Br D) 2b: Attacker's zone: >> B and C signs (Br C) >> >> The owner should do step 2a before the attacker is able to do 2b. > > > Right, but 2a can happen as soon as the owner notices something hinky > with the zone or suspects a compromise. 2b can't happen until 1b has > been out in the wild for the entire Add Holddown time otherwise the > attacker is throwing away its only mechanism for installing new trust > anchors. Correct. >>> Yes, D is the owner's replacement for B. I don't name the keys >>> as "C" and "D" in section 6.1, but that's what's happening. >>> >>> You used "C" as the "Attacker's new trust anchor" in this series >>> of messages. I probably would have used something more disjoint >>> in the explanation. >>> >>> >>> So to clarify. >>> >>> 1) Start with two trust anchors (A B) and a ZSK (Z) (let Z stand >>> for any of the regularly generated ZSKs) 2) B is a stand by key - >>> it's a trust anchor, but not used for regular quarterly signing >>> 3) The normal DNSKEY RRSet is "A signs (A Z)" >> >> Since B is a standby key, it should be "A signs (A B Z)" > > > No. Once B is added as a trust anchor, it need not be included in > the root DNSKEY RRSet. If B is not signing anything, there is no > reason to include it. That depends on your key rollover mechanism. In the Double-DS rollover, you don't need to add B, in Double-KSK and Double-Signature you do. But if you want B to keep as a trust anchor at the validator, you better leave it in the DNSKEY RRset, otherwise it goes to the `Missing` state, an abnormal state. That can't be good. In the Autotrust implementation, missing trust anchors will be removed after a (fairly long) time, otherwise we might end up with a bunch of valid, but missing, trust points which are no longer in use. That sounds like a weakness in the system. >>> 4) If A or B is compromised then generate a new key pair C 5) >>> Assuming A is compromised issue a new RRSET "A and B sign (Ar B >>> C Z)" and propagate that for twice the add hold down time. (the >>> add hold down time to get the bits set, the additional time to >>> pick up stragglers - the additional time is just suspenders and >>> belt) 6) Once you've done (5) for long enough, issue a new >>> "normal" RRSET "B signs (B Z)". C is now a standby key. >> >> 6) should be "B signs (B C Z)". > > > Same thing as above. Once C is a trust anchor, unless its actively > signing something, there's no need to include it in the DNSKEY RRSet. > [However, you increase the "take" rate for resolvers the longer you > leave it there - especially if there are intermittently connected > resolvers] Same thing as above. You want to keep it in the DNSKEY RRset, or the validator will mark the trust anchor as `Missing`. > Keys enter the trust anchor set only by being present in the root > DNSKEY RRSet and signed by a previous trust anchor for a minimum > period of time (the Add Hold Down). Keys leave the trust anchor set > only through revocation. Right, and to me that sounds like a weakness. Missing trust points should be cleaned up too. Best regards, Matthijs > > Mike > > > > > > >> Best regards, Matthijs > > From nobody Fri Oct 24 01:33:56 2014 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFB61A1A24; Fri, 24 Oct 2014 01:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkba9fiPthID; Fri, 24 Oct 2014 01:33:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2051A19E5; Fri, 24 Oct 2014 01:33:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNZ58599; Fri, 24 Oct 2014 08:33:51 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Fri, 24 Oct 2014 09:33:48 +0100 From: Hosnieh Rafiee To: "Int-area@ietf.org" , "dnsext@ietf.org" Thread-Topic: Review request - new version of CGA-TSIG draft - draft-rafiee-intarea-cga-tsig-11 Thread-Index: Ac/vZTsfRGiYQN2JTa2q1UC8l8lSzw== Date: Fri, 24 Oct 2014 08:33:48 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A4C31B@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/i3vIPQsSXkmKPM6Hg8CfuD2q71o Subject: [dnsext] Review request - new version of CGA-TSIG draft - draft-rafiee-intarea-cga-tsig-11 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 08:33:55 -0000 Folks, I have revised CGA-TSIG document . You can find the following summary in th= e introduction as well. Just to motivate more people to review the draft, t= he following is the description of the mechanism. Thanks Joel Halpern for his comments and reviews which helped to improve it= s readability and content. I would love to receive your inputs on this version so that I know whether = now it is easily readable and understandable. :-) Thanks, Best, Hosnieh < https://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-11 > ------------------------------ Overview of CGA-TSIG/e Mechanisms The purpose of CGA-TSIG and CGA-TSIGe is to minimize the human intervention= required to accomplish a shared secret or key exchange (automation as much= as possible), secure authentication, with the end result of providing data= confidentiality to prevent DNS spoofing. Minimizing the amount of human in= tervention reduces the vulnerability to attacks introduced by human errors.= As explained earlier, CGA-TSIG/e can be used to assist DNSSEC server in la= st mile of Internet. CGA-TSIG/e supports both IPv4 and IPv6 scenarios. In t= he IPv6 scenario, the algorithms use Cryptographically Generated Addresses = (CGA) [RFC3972] or Secure Simple Addressing Scheme for IPv6 Autoconfigurati= on (SSAS) [1]. Both CGA and SSAS provide the nodes with the necessary proof= of IP address ownership by providing a cryptographic binding between a hos= t's public key and its IP address without the need for the introduction of = infrastructure. For example, in DNS stub resolver to resolver scenario, CGA= -TSIG provides this secure authentication by receiving the IP address of a = DNS resolver via an option from a secure Router Advertisement (RA) or from = DHCPv6 server that is protected via SAVI approaches [savi-dhcp]. When it (c= lient) wants to resolve a query, it sends a DNS query message by only setti= ng algorithm type to "CGA-TSIG" without signing this message or adding any = more information. This is because resolver does not need to verify the clie= nt and a client can be anonymous. If resolvers supports CGA-TSIG algorithm,= then it sends a DNS query response message by setting algorithm type to "C= GA-TSIG", include required parameters such as its public key in CGA-TSIG da= ta (to be verifiable on client), sign this message and submit it. When the = client receives this message, since there is a binding between this public = key and the IP address of the resolver, by verifying the signature, the cli= ent makes sure that this public key belongs to the target resolver. In othe= r word, public key of the resolver is sent in a same message as a DNS query= (no separate message is required). In case of DNS confidentiality (CGA-TSI= Ge), if this client haven't already cached the public key of the resolver, = it sends an empty DNS query message by only setting the algorithm type to "= CGA-TSIGe". Then the resolver knows that it should submit its public key to= the client. Since this binding exists, client can use the public key of th= e DNS resolver to exchange a random value (called shared key). Then DNS res= olver uses AES or other secure symmetric algorithm to encrypt all DNS messa= ge with this random value received from this client. In case the network is not secure, user can easily introduce the IP address= of trusted resolver (or select home resolver from the list of trusted reso= lvers in its computer).=20 In IPv4 scenarios, the algorithms use the hash of public key as an authenti= cation approach. For example, in resolver scenario, the client receives the= DNS resolver's hash of (IPv4 + public key) from a DHCPv4 server that is pr= otected by SAVI approaches or other monitoring approaches. If the network i= s not reliable, then this hash value can be introduced once manually to the= stub resolver. The other option is that when the client receives the IP ad= dress or hash of (IPv4 + public key) securely from a secure DHCP server or = an option in RA message, it caches this value in a list of trusted resolver= (called trusted list). Whenever there is no trusted resolver available (li= ke public network), the implementation can provide a way for the user to se= lect one of the trusted resolver stored in this trusted list or it can be s= ome random selection mechanisms. This will avoid any manual configuration f= or the user. However, if this trusted list is empty and the network is not = reliable, the only way to provide this reliability is to introduce the DNS = server's IP address manually. Similar to IPv6 scenario, the public key is s= ent by the resolver in a DNS query response message. When this client resol= ves any query response, it compare the hash of (resolver's source IP addres= s + public key) with what is available on its own and if there is a match, = it verifies the resolver and accepts the message. In case of DNS confidenti= ality (CGA-TSIGe), the same approach that is explained in the prior paragra= ph can be in use. The detail steps for these scenarios are explained in nex= t sections. --------------------------------------- [1]< http://tools.ietf.org/html/draft-rafiee-6man-ssas-11 >=20