Re: [DNSOP] requesting WGLC for 5011-security-considerations
Michael StJohns <msj@nthpermutation.com> Thu, 06 July 2017 17:33 UTC
Return-Path: <msj@nthpermutation.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6594813185E for <dnsop@ietfa.amsl.com>; Thu, 6 Jul 2017 10:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
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 FVbV9GHcNJ4R for <dnsop@ietfa.amsl.com>; Thu, 6 Jul 2017 10:33:22 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56EF13185C for <dnsop@ietf.org>; Thu, 6 Jul 2017 10:33:21 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id v143so8355009qkb.0 for <dnsop@ietf.org>; Thu, 06 Jul 2017 10:33:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=fOKZgg/zfGzQ4ShRzbmt7vJknTF1e8qhI/E+2dW35NE=; b=qRmH4XfyazJPoaNHuUOHjVyx5uPfOhlJ+Ymi9Q6SPMCQQiSYGYD3pq6Ejo6w+pLfF7 61RbPKePWE1cOZn8MmoZc3L9AW5kc8uLZ5cFD1Hi5fKNw9vZgjpwLAiA/1jsrXbJkAWS Mm9MoZR8iYr9iapFv0qToEEXuVgqQUC3iTVPFBf6ATBBLl2X0xWU8IH5eT7G65f5JlfF TkDP1ca+gSiUNOMmFPmm+NfyRStUcaG5WStTxRRmJzyy5kO0WAlwiL6BzTYfPLOW+YOw DnQfbdHp+gbTpcX4OYdq4JH+wwD1XRSlVn7EzMkSoJLPPv6IUFQf87VrgcNnp12IuC4S +p+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=fOKZgg/zfGzQ4ShRzbmt7vJknTF1e8qhI/E+2dW35NE=; b=NZ8H+OrLFrVgZr6A2xviF/Qh85/2M1wpJBhPuzDC/iHR+OMqfbaqSlz0rW7vF9v325 ySpBngTsONuAo4Hf4fWPk5hz7WDlhr2XU8vrn/yYBtxew1sRy0TzwpfXqcPIx0R7CGZu 0l/iP6DfOIBWdf7uvPXGREvlol5QN9DmD+9EPbWiK3ro+JQ1BBCivFa8WpXdGYw+3dRk qkzAJUyGybibiYEZ+6k8/we0RmpMYGbLmTO3yEv7Ui5bur2GI2jLhrdvoSgGJT6DQDh/ zVTZvHCInPWvD1TH38duE7hW9/bN0+E9GueHqhePYISU3+G10jWBJUiuS0JOH2RxPDdX ybbw==
X-Gm-Message-State: AKS2vOy+0monsYXKJk40BPM20wH2xolyqmdKE6c/QcLACzWgX/B3B/xV /y5dZER1ZviA5PdduNw=
X-Received: by 10.55.75.204 with SMTP id y195mr63288997qka.183.1499362400498; Thu, 06 Jul 2017 10:33:20 -0700 (PDT)
Received: from [192.168.1.100] (c-68-83-216-246.hsd1.md.comcast.net. [68.83.216.246]) by smtp.gmail.com with ESMTPSA id j17sm581915qta.49.2017.07.06.10.33.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 10:33:19 -0700 (PDT)
To: Wes Hardaker <wjhns1@hardakers.net>
Cc: dnsop@ietf.org
References: <ybl4luqq05v.fsf@w7.hardakers.net> <CANeU+ZBzP+0REnZf0=_t60oXD_oA1nbYMRGcoFQ221buJb8YBw@mail.gmail.com> <ybly3s2le1m.fsf@w7.hardakers.net> <CANeU+ZD7NF07hZdsQT74bZar41dW6i2k6zaNvVnbRg0WYP4tMQ@mail.gmail.com> <yblmv8il906.fsf@w7.hardakers.net>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <8c53d2b7-afe7-fe83-27b0-11297d896ad7@nthpermutation.com>
Date: Thu, 06 Jul 2017 13:33:18 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <yblmv8il906.fsf@w7.hardakers.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eh1bGp1wjkRzHX4OtX5tZrwLMMs>
Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jul 2017 17:33:24 -0000
On 7/5/2017 8:11 PM, Wes Hardaker wrote: > Michael StJohns <msj@nthpermutation.com> writes: > >> That's not actually a plus you understand. Mike > Sure it is. We're down to the point where large changes aren't needed :-P I'm sure you think that... but the small changes you've made to address some of my comments haven't gone far enough. There's also a need for a grammar and syntax pass on the document. Here's what I've got so far (in document order rather than order of importance): 1) Use "exclusively" rather than "only" where you can - "only" has some issues with misunderstanding. E.g. in the abstract you have "only recently" which can be interpreted applying to "recently" rather than meaning "exclusively" with " recently added DNSKEYs" Instead in the abstract: "... before exclusively signing with recently added DNSKEYs" 2) In the introduction - "validators can update" vs "validators can extend". 3) In the introduction - same issue with "only recently" 4) In the introduction - "ceasing publication of a revoked key" vs "removing a key from a zone" 5) Section 1.1 - What is the definition of "rolled"? Your use of it doesn't match 5011s and it's not defined either here or in 4033 or . Also "before signing a zone" - I don't think this is exactly what you asked them and the summary is probably inaccurate. 6) Section 2 "which apply to" vs "as required from". 7) Section 2 "Note that it does not..." - which "it" are you talking about? 8) Section 2 "using only recently" - same issue as above. 9) Section 2. New para at "Failure of a DNSKEY..." 10) Section 2. "... leaving that key in their trust anchor storage beyond the key's expected lifetime." vs "... leaving a key in their trust anchor storage beyond their expected lifetime" -"their" applies to two different things 11) Section 3: Attacker. "An entity intent..." vs "An attacker intent..." - self referencing definition problem 12) Section 4.1: This doesn't actually describe what's in 5011 - specifically bullet 3 was modified to clarify your concerns, but isn't what was in 5011. You need to have both here. 13) Section 4.1, bullet 3: Same problem with "only". Instead "Begin to exclusively use recently published DNSKEYs..." 14) Section 4.2 last para: This is only an attack if the private key is compromised. In which case, with only a steady state of a single key, you've got lots of other problems. Basically, in your one in one out with a steady state of one model, once the current private key is compromised you have no ability to fix the problem. But getting the numbers for figuring out when this change becomes "sticky" correct is useful. 15) Section 6 - general comment. You're doing interval calculations and you want to do date/time wall clock calculations instead. While the 5011 values are based on intervals from the RRs get to the validator, the publisher has to be looking at absolute times first (e.g. signature inception and expiration, original TTL) and then deltas from those. [Note, this is NOT a new comment - I've made it previously and strongly] 16) Section 5.1.1 - You're missing a *very* important point here - that DNSKEY RRSets may be signed ahead of their use. You need to assume that once signed, they are available to be published - even by an attacker. So wherever you have "signature lifetime" you want something like "latest signature expiration of any DNSKEY RRSet not containing the new key" or at least you want to calculate the date/time value based on that. 17) Section 5.1.1 doesn't actually apply if you use the 5011 rollover approach (section 6.3). E.g. K_old (and any RRSets it signed) will be revoked the first time K_new is seen and K_standby is the signing key. At this point this reduces to a normal denial of service attack (where you prevent new data from being retrieved by the resolver). You'd need a different section to do that analysis. [And thinking about it, why is there any practical difference between this attack and a normal denial of service attack in the first place?] 18) Section 5.1.1, T+35: "since the hold down time of 30 days + 1/2 the signature validity... " - Two items: Wordsmithing: The hold down time is just the 30 days, not the plus 1/2... which I *think* given the reference to 2.3 is actually the queryInterval. clarify please. And queryInterval is not actually 1/2 the signature validity - its the MIN (15 days, 10 days (sig life)/2 and 1 day(orig ttl)/2) or 1/2 a day. 19) Section 6 - the formulas are wrong. I also don't understand where you got MAX(originalTTL/2,15 days) - there's no support for this in the text. The final formula should be: EarliestDateWhereAttackFails::= latest SignatureExpiration of any DNSKEY RRSet not containing the new key waitExpirationDate = EarliestDateWhereAttackFails + 2*queryInterval (from RFC5011 section 2.3) + holdDownTime + slop (let's call this twice the query interval or some other number - its really there just to deal with an attacker preventing the last RR_New from being delivered) In the given example, assuming a 5/1/2017 00:00UTC inception date for the RR_Old, an 5/1/2017/00:01UTC inception date for the RR_new, a consistent 10 day signature validity and a 1day original TTL. EarliestDateWhereAttackFails == 5/11/2017 00:01UTC queryInterval = 1/2 day waitExpirationDate = EarliestDateWhereAttackFails + 30 + 2 or 6/12/2017 00:01UTC - 42 days after the last old RRSet was signed and 32 days after the last possible expiration date of an RRSet without the new key. So assume you sign both the new and old RRSigs with one seconds difference with identical parameters: At T=0 a publisher sends RR_new At query interval, and until EarliestDateWhereAttackFails and attacker somehow manages to intercept RR_new and substitute RR_Old - alternately, the attacker can let RR_new through until the next step - probably the more reasonable approach. At T=EarliestDateWhereAttackFails-1second attacker intercepts RR_new and sends its last valid RR_old At T=EarliestDate+queryInterval resolver receives another RR_new and starts the hold down From T=EarliestDate+queryInterval until T=EarliestDate+queryInterval+holdDownTime every queryInterval the resolver gets another copy of RR_new At T=EarliestDate+queryInterval+holdDownTime+queryInterval resolver gets the final copy of RR_New it needs to trigger the installation of the new trust anchor An attacker can prevent or delay the installation of the trust anchor by preventing delivery of RR_New (or subsequent RR with the new key), but that's sort of the definition of a Denial of Service attack and really no worse than keeping say "A" records from the resolver. In any event, the point needs to be made that this attack - while real - is a "retail" attack that would be difficult to prosecute by a single attacker across a broad range of end-entities. This goes to the general model that no publisher of DNS data knows each and every consumer of that data, nor can wait its publication on every consumer getting published data. The data protocol for DNS is unidirectional and the update protocol in 5011 was designed with that in mind. 20) The value in 6 regardless of what it is is the wrong value for revocation. revocationPublicationWaitTime is basically EarliestDateAttackFails + queryInterval + slop. Revocations take place immediately. You can delay them only as long as you have old valid signed RRSets. So - not ready for last call. Mike
- [DNSOP] requesting WGLC for 5011-security-conside… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Paul Hoffman
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Matthijs Mekking
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Matthijs Mekking
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker