Re: [DNSOP] Review of draft-ietf-dnsop-rfc5011-security-considerations-13, was Re: [Ext] IETF meeting prep and what

Michael StJohns <> Sat, 19 June 2021 19:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C4A33A1DE0 for <>; Sat, 19 Jun 2021 12:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.335
X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.338, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wr-lztIH4RmM for <>; Sat, 19 Jun 2021 12:28:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04F3F3A1DDF for <>; Sat, 19 Jun 2021 12:28:54 -0700 (PDT)
Received: by with SMTP id c22so2661767qtn.1 for <>; Sat, 19 Jun 2021 12:28:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=5yOcx9BrpWE7/xY7OE4p9io1Ik1HQIWt2YGmAF6f/lM=; b=mH0LQFc/HTznN1OXzFZU+pbJf2OkvtTynT6maYiIk8idtcPurYxccC4yoGDkT6uCPs s3A2ZD2Wv/AeUITsm/B+1oJyFmQ5x5II6JbARl3fR5UHjJKK0vr0LOpt/Iltscd5AwC+ 959hh0MrtrOfUSTJpvQs0bsuIFhkqFnLukdYjPnHZBjgwH9pmK6hsLwpL/t4Ghx27VID bpfU2T9NmjrZGxwvkMm6WMkC6XnTS0w6QCX28MOyvCuyE7Srtkz6A7yypJP8QQeIwKDb RoWuwmztBzL8E2nGvNYzir5NDVVb8FJcSMVrv7GJJdPynOr6eurisjTo6T/bZWLpg4Yu YlEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=5yOcx9BrpWE7/xY7OE4p9io1Ik1HQIWt2YGmAF6f/lM=; b=ogjSFHE5xVzu5Tlc3r9/cJita5iLB1SME7o03YWSzLm93/Ft6G5p+gX+xV8oQTnfgZ 1DMF/EZGST5aqp++kN7i59bPDYf5+U1M2ixKofIpa3cR2q+YfE64sJaGfQjYrPwNjHMw QojKn5hFKhDVN0xEKnW8619/mfM8wrmAu8JNH5nXEEdaOxEDPC0qppr5zaK8Bz2YEZPd +3boU6W1Df3NLIX6C/zRpghiQSRaaQPJs3FSOfkqxMsrKYRR6GX/JZrIwy5kiBWY/Cme mL+4jzxcyGfDl2S3rWSfuKzxJ4jGUxC82UaAEGPnWHpqjVtZa6HREtZ0dBUsR4uZeRgP AFUA==
X-Gm-Message-State: AOAM531RbMALFy5WBWYsyeTlQSLPa0fgeUXX9PRe0eBjq675mI9TINxy lTT9at0LgdG13iHy4SaQEd9EdM8QyboWzuXL
X-Google-Smtp-Source: ABdhPJy06K075Sd4F15N16vZvviKTEUivQcfknX5A6ok/PvV1Z2JPFuJguEhpHBrg62oOIiFC/8Sog==
X-Received: by 2002:a05:622a:1302:: with SMTP id v2mr15958732qtk.70.1624130932813; Sat, 19 Jun 2021 12:28:52 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id g19sm7537226qtg.36.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Jun 2021 12:28:52 -0700 (PDT)
References: <> <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Sat, 19 Jun 2021 15:28:50 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [DNSOP] Review of draft-ietf-dnsop-rfc5011-security-considerations-13, was Re: [Ext] IETF meeting prep and what
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 19 Jun 2021 19:29:00 -0000

On 6/18/2021 7:11 PM, Paul Wouters wrote:
> Section 6.1.7 confuses me a bit as it defines a numResolvers variable,
> and uses that to calculate an acceptable new timing period. To me it
> feels that number of resolvers should not matter, as we should stick
> to the formal time where all resolvers are either updated or no longer
> updatable. This arguments also bleeds into Section 6.2 where it is used
> indirectly.

Hi Paul -

There's a bit of discussion on the WG list but basically:

1) Given various parameters, calculate the earliest date at which a 
publisher can assume at least 1 resolver with perfect connectivity (e.g. 
all questions answered when asked) was able to install the new trust 
anchor.   Note that you figure this assuming only a single resolver and 
non-synchronicity between publisher and resolver which means the 
earliest date for the publisher is the latest date the perfect resolver 
would do the install of the new trust anchor.

2) Given set of N resolvers with imperfect connectivity (e.g, online but 
with occasional lost message/retransmits using 5011 timing) where the 
imperfection is characterized as L% chance of any given message being 
lost, how much longer after (1) should you wait to get to the 
statistical point where K% of the N resolvers have been able to install 
a new trust anchor?

(2) represents a safety factor and is calculated based on N, L and K.   
It ignores the set of offline resolvers in the calculation, because 
there is no way to characterize them.

The question "all resolvers updated" is not an answerable question nor 
one answered by the document.   "Statistically, 99.9999% of resolvers 
have updated" is an answerable question with some margin of error 
assuming N and L can be characterized.  The size of N has a small but 
important impact on the final result.

Later, Mike