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

[Michael StJohns <[e-mail]>]

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 
interval.

Later, Mike