Re: [DNSOP] requesting WGLC for 5011-security-considerations

Michael StJohns <msj@nthpermutation.com> Sun, 16 July 2017 09:21 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 AF3A512F280 for <dnsop@ietfa.amsl.com>; Sun, 16 Jul 2017 02:21:57 -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 12XT4joQpYEK for <dnsop@ietfa.amsl.com>; Sun, 16 Jul 2017 02:21:56 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 E5848127058 for <dnsop@ietf.org>; Sun, 16 Jul 2017 02:21:55 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id t70so16673920wmt.0 for <dnsop@ietf.org>; Sun, 16 Jul 2017 02:21:55 -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=ISZkNSDRTozujSdjlp1jsezB+4DJOu0vVX/WPIM9Lys=; b=PQ1qwFlBdSozabXAuH41CeURsG8KjGpa1w6rJtM4KXdLObHxlVdGm7xffk9KRMWFym dXxgqVdmuTACaPTkvslRG0y7JfWsqFrFOhcFSWJ/28uy5+d11PF3w4Ot6+o6HxOjUuOb I2gTutOj3m6H7q0g+Z2yYnCJFHi7bT+RkULuQqizy6tj9FY+1HlNwfO+Dyv/Ldr1Zh6p K71Z8tOsL46JnpMKxbZx1cmP6YJNPOBejmZunnnGtI79Sqm4n1auA81EIvHvB4yM7s8q 7UxrIiUay10RYdb8RW1dog0a201LcE7W15GHF988yZAakF9o8mRpbmQ+KK4aWUScU2sk Py9Q==
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=ISZkNSDRTozujSdjlp1jsezB+4DJOu0vVX/WPIM9Lys=; b=huybnOfWo0dwAAtlT2UxywbinvhjMJSfjDXSsz43jRHLjerv8apa87t2BP22C9Na+P qCQgGL2oYdDyIrpBBBoHTe+4vX7KrpZP/XS51pFv05vfpGx4IzFO/C8jJpqD1esicwd/ Bd1bMGCD3oTtg2HhQ3NubRcZhgugPkfSmo0IVuh1DSsTo2a7UB1/7hismsiJJC3Fhuzc rZgAarBYMpcNiNv/CsYWTA7MdMA4xN8drXwPXis0DcNjokDNG9+Z3aOYMfSLbJK3vfo7 T1iUUiaAMlv/68jnIkdqQj/L598QKnjA/y21AgZB5Of6v5QKoe4WQFVfTcDRV9lJrwzs d5kA==
X-Gm-Message-State: AIVw1133MKnEW8ZE7auQBsbyEw8p0TUp4jd7NlM5am1+kbbdBGSOzkwC cDiLq9tiW9JqS7vzu9M=
X-Received: by 10.28.158.11 with SMTP id h11mr1023130wme.88.1500196914132; Sun, 16 Jul 2017 02:21:54 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:9422:6544:1cd4:352c? ([2001:67c:370:128:9422:6544:1cd4:352c]) by smtp.gmail.com with ESMTPSA id b195sm15261913wmf.0.2017.07.16.02.21.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 02:21:53 -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> <8c53d2b7-afe7-fe83-27b0-11297d896ad7@nthpermutation.com> <ybl1sptlazr.fsf@w7.hardakers.net> <a1af5a54-8d50-698d-71e2-87f6dbeb9ca2@nthpermutation.com> <yblo9sxpfb8.fsf@wu.hardakers.net> <yblh8yhmucf.fsf@wu.hardakers.net>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <77997330-f10c-22b3-4683-68e6d2a37cc0@nthpermutation.com>
Date: Sun, 16 Jul 2017 05:21:51 -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: <yblh8yhmucf.fsf@wu.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/SdwtXkNOFfc2OBsDR_jmwsPORsI>
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: Sun, 16 Jul 2017 09:21:57 -0000

On 7/12/2017 1:35 PM, Wes Hardaker wrote:
> Mike,
>
>> 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 in short, the advice in 5011 section 6.6 step 3:
>
>     3.  After 30 days, stop publishing the old, revoked keys and remove
>         any corresponding DS records in the parent.
>
> Has nothing to do with a needed wait time (because keys are revoked
> immediately) but rather the above 30 days is really just a suggested
> time for operational practice?

In your "prevent the add of a new trust anchor" attack, you only need to 
intercept one query/response pair over a period of queryInterval + 
EarliestDateAttackFails.  In the "prevent revocation" attack, you need 
to intercept ALL query/response pairs for at least 30 days (in the 
example - that's 60 Q/Rs) - quite a bit harder and pretty much 
impossible to do widespread.    Also, 6.6 talks about deletion of a 
subordinate trust point by revoking all the trust anchors - depending on 
the behavior of the resolver (which I had many arguments about with 
various vendors), trust will generally be traced through the new DS 
record(s) with the absence of the old trust anchor key  in the DNSKEY 
RRSet so the presence (or absence) of the "revoked" key in the 
resolver's trust anchor set is mostly a non-issue once the DS is published.

Given that I can think of only a few possible subordinate trust points 
and none of them will probably ever be deleted, I probably wouldn't 
change this guidance.    If we were going to change the guidance, it 
wouldn't be as simple as the publish new trust anchor model - you would 
need to consider the expiration of the Parent DS (if any) as well as 
expiration of the child DNSKEY RRSet in picking a new value.


>
> In 2.4.2 you have:
>
>     The remove hold-down time is 30 days.  This parameter is solely a key
>     management database bookeeping parameter.  Failure to remove
>     information about the state of defunct keys from the database will
>     not adversely impact the security of this protocol, but may end up
>     with a database cluttered with obsolete key information.
>
> Which seems to back this up (though I'm not convinced that there is no
> security ramifications of having old trust anchors around; else why
> delete them?)

Nope - two different parameters with the same value.  The first was a 
publication guidance, the above was simple database management guidance 
for the resolver.



>
> So in the 5011-security-considerations draft, I agree with your point
> that the right amount of time to wait should be changed to replayTime +
> queryInterval + slop.  Thanks for pointing that out.  (though it's worth
> noting that replayTime + queryInterval can be longer than 30 days).
>
If you mean that replayTime ~= last validity date/time of the old DNSKey 
RRSet with the to be removed keys - then yes.  But please be clear and 
precise in how you define this term in the document.