Re: [DNSOP] Responding to MSJ review of the previous rfc5011-security-considerations

Michael StJohns <> Thu, 19 October 2017 13:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 815C2132C3F for <>; Thu, 19 Oct 2017 06:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 i_CR8h5lPeN7 for <>; Thu, 19 Oct 2017 06:25:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B2DD11241F3 for <>; Thu, 19 Oct 2017 06:25:50 -0700 (PDT)
Received: by with SMTP id k31so14380075qta.6 for <>; Thu, 19 Oct 2017 06:25:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=wjgNLrLbYPHeKEDZerzfH4udK/7mit9VEujAH2pDWQg=; b=XaegEZnQQ0Pa4f7U4G+ss6gKkXWh5CvENFZCIHQ6MLRT2G33ZRApg0zSokGE7TxTIU D48xEEUe3sUmvGO1hU2m/qnuqt0r1YtO6BuACq0x7Jjx8ZOULlvy4/Q4iP5f5Fg5MIxV T6JPZ1GDWGxlIr1e8dgviv6s7eSC+q5RzhAuq7m1fqa2MyU/2ckyEeXAXXD4t5ZaW1yM FD2RiIoCPggyyV1sJjfayRomkftDyEkUu379+ikMI35VO+gPSODX8PuU0LlKgb3lMZoj 6t5MBjO7rwmFPFyfrFHHHHcJeRnO9/wbtK5tWsj12TPRcuoSvwoPp7IXe1zMn0v+D5Vn 8Xwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=wjgNLrLbYPHeKEDZerzfH4udK/7mit9VEujAH2pDWQg=; b=SHApsaMwA347VbtJ2UrtF9qp7eEMXv4iYJxqy1da8R5DPHFfM0nJhwKZLfXyansmYr pROY6YMw3lCYIkwBr/KpaSFVHZ9TqCwT5WJUqZeYoso+tBVw4E5089tnM3jbiHZYkh0L jvZVmG8bznh3WmLwIUxP0hs7o7hHRozCpuQf3s+/WhfDsSyx+FOl/mlofMokrA+ohZ1S kv1dN8rFByfeymlS5ANvHiuH0tzq5zo7jt8+lyDUIu6HWeh5x/YNyCIWiDSHMjQ4cY2C kLxYGgUoPLnPOXcL9kFdpJ3hdAbQKKPyQbSEvv5nElgWzb0Z43SLEkPDDjrPB17uY3Cr /24A==
X-Gm-Message-State: AMCzsaVYmkwoqW1Stq0GSpHp6YrNsMp7Mophv564L7YWuJ/t0Es0pUsK hw+rZSOizMZ3B0zaYubhIoDky7rv
X-Google-Smtp-Source: ABhQp+Tn59816J8BXuY7P7BTJr3mC+gfcmBp3ZkbWVXyQyORRAgH9Qzv7Bou+zZUIiiRmy9kpM8J/Q==
X-Received: by with SMTP id g21mr2084761qtb.183.1508419549170; Thu, 19 Oct 2017 06:25:49 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id p8sm9093698qki.57.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 06:25:47 -0700 (PDT)
To: Wes Hardaker <>
References: <> <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Thu, 19 Oct 2017 09:25:45 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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] Responding to MSJ review of the previous rfc5011-security-considerations
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Oct 2017 13:25:52 -0000

On 10/18/2017 5:21 PM, Wes Hardaker wrote:
>>      You said in 4.1:
>>      which the principle
>>          way RFC5011 is currently being used (even though Section 6 of
>>          RFC5011 suggests having a stand-by key available)
>>      And then in  T-1 you say:
>>         Note that for simplicity we assume the signer is not pre-signing and
>>          creating "valid in the future" signature sets that may be stolen and
>>          replayed even later.
>>      But - "the way RFC5011 is currently being used" is with "pre-signing"
>>      and "valid in the future" signature sets.   So you want to have your
>>      cake and eat it too.     You're now both not dealing with the way 5011
>>      said you should do things nor are you dealing with the way that the
>>      root actually does things.
>>      All of this can be fixed by going to a wall clock model which is the
>>      way the publisher works vs the interval model which is only
>>      appropriate for the client.
> I understand that's how you'd structure the document.  For me,
> I believe it's easier for people to understand the problem as
> structured.

This is unfortunately a deflection.  The document is still being 
two-faced in that it is claiming to address "the way RFC5011 is 
currently being used" but ignoring the "pre-signing" and "valid in the 
future" signature sets in its discussion of the issue AND the solution.

With respect to below, I believe that "most people" (who are doing 5011 
in the way you've described) would want the answer to the question: 
"When is it safe for me to revoke all of the older trust anchor 
keys?".   When they discuss it with "other people" they will use a fixed 
date not "5 days from when I did the calculation which was 2 days ago so 
three days from now".

This isn't about a structuring preference, it's about having 10 people 
doing the math at different times and having 100s others get the same 
understanding of the answer when the first 10 discuss it.

Even the Root 5011 folks discuss their timings in terms of actual 
dates.  Yes they get to the dates by doing interval calculations, but 
what matters are the dates and I haven't heard anyone say otherwise.

>   The example walk-through is designed to be simple
> for learning about the issue, which is already complex enough.
> This topic was brought up on the list before and in Chicago and
> the consent was to leave it as is, though there wasn't a huge
> number of voiced opinions.  We designed the document to come at
> the topic for human understanding, and I believe most people
> think about the problem as a delta from the time they sign and
> publish the zone.  I believe that coders will implement it
> according to how they need to given their software.
> If you feel strongly about this, please encourage others to
> chime with requests for change too in order to shift consensus.
> At this time we don't plan to change the document to reflect
> your preferred style.
>>     You continue to have a problem with "sigExpirationTime".
>>     > The amount of time remaining before any existing
>>     > RRSIG's Signature Expiration time is reached.  Note that for
>>     > organizations pre-creating signatures this time may be fairly
>>     > lengthy unless they can be significantly assured their signatures
>>     > can not be replayed at a later date.
>>     the problem is:  Amount of time measured from when?     (and it should
>>     be "latest RRSIG's Signature Expiration time is reached" at least.
>>     > sigExpirationTime will
>>     >        fundamentally be the RRSIG's Signature Expiration time minus the
>>     >        RRSIG's Signature Inception time when the signature is created.
>>     This is no longer fundamentally the difference between one RRSig
>>     inception and expiration time.  You can't even describe it as the
>>     difference between the earliest inception and latest expiration
>>     because that changes as the earlier RRSigs expire.   The only fixed
>>     value (and easiest value) is "latest expiration date". You could say
>>     "latest expiration date - now" which then gets added to "now" to get
>>     back to lastest expiration date.....
>>     Please, please please just move to a wall clock value based on the
>>     latest expiration date plus appropriate intervals.  All the minor
>>     twiddles you've done to try to avoid doing this have made the document
>>     less clear.
> I've changed the wording to your "latest...".  Thank you for the
> concrete suggestion.
You're welcome.  However, all the rest of these are also "concrete 
suggestions".  Or do you mean "actual text that I can incorporate"? I'm 
happy to edit the entire document to fix the issues if you want to give 
me the edit token.

>   As to "when" it amounts to the current
> value time(), which is indicated by the "The amount of time
> remaining...".

So 10 people doing this have to publish both the interval they calculate 
and the time() value at which they did their calculations?  So the other 
10-100 people can figure out "when"? I think not.

> Again, this is written from the point of view of
> a human wanting to calculate how long the need to continue waiting.
And it should be written from the POV of a human wanting to tell a group 
of people WHEN something will be done.   Sending out "we're going to do 
this in 45 days" is problematic especially if I re-read the email 10 
days after it was sent or if the email was delayed.    Sending out 
"we're going to do this on January 1st at 10am" or "we're going to do 
this in 45 days which is January 1st at 10am" is going to be more useful 
than a simple interval.

I can't figure out why you continue to argue as you do - the output of 
this calculation is a date and time at which it is safe to revoke the 
old keys - not an interval.  In fact you have to work hard to make it an 

Later, Mike