[DNSOP] Re: Call for adoption: draft-fobser-dnsop-dnssec-keyrestore-01 (Ends 2026-02-27)

[Benno Overeinder <[e-mail]>]

Dear WG,

With this message, we close the call for adoption.  Apologies for this 
being later than the originally planned end date of late February.

The working group has reached consensus to adopt the draft as a WG 
document.  During the call for adoption, it was suggested to broaden the 
scope beyond HSMs and address key recovery more generally, regardless of 
the method used.

Best,

-- Benno
for the DNSOP WG chairs


On 26/02/2026 16:03, Petr Špaček wrote:
> On 13. 02. 26 21:28, Philip Homburg wrote:
>>>> This message starts a dnsop WG Call for Adoption of:
>>>> draft-fobser-dnsop-dnssec-keyrestore-01
>>>
>>> I am not in favour of adopting this document. The hypothetical
>>> scenario where one has lost the key, but the zone is still working
>>> seems fairly unlikely. It is far more likely one finds out about
>>> the missing key once it is needed to sign something and can't, at
>>> which point it is going to be too late.
>>>
>>> I also don't think people who messed up and are in a panic, are
>>> going to search for an RFC on his to recover from their mistake.
>>
>> I'm in favor of adopting this. Even if it doesn't get adopted, I plan
>> to reference and possibly summarize it in our documentation.
>>
>> Many signers sign a lot more frequent than is needed to keep signatures
>> for expiring. Many TLDs have frequent updates that require signing.
>>
>> For zones without frequent updates, it is more pleasant to refresh
>> signatures incrementally. That simplifies scheduling.
>>
>> And even if a zone with very infrequent changes only resigns when needed,
>> a prudent operator can resign the zone one week before signatures expire.
>> So there is plenty of time to recover if something goes wrong.
>>
>>> A side effect of RFCs like this is that it will be misused by
>>> opponents to say that DNSSEC is so brittle, it needs RFCs to talk
>>> about operator errors.
>>
>> So we should remain silent about operator error to make DNSSEC look good?
>>
>> I think it is the other way around. People who think about deploying 
>> DNSSEC
>> worry about operator errors and make plans for recovery. Currently
>> the main approach is to go insecure, which is very unpleasant.
>>
>>> This could make a nice blog post, but I don't think meets the bar
>>> for an RFC.
>>
>> Can you explain how high the bar should be for an informational RFC?
>>
>> This draft describes a techincal problem and provides a technical 
>> solution
>> for that problem. Sounds like something that can be documented in an RFC.
> 
> All points well made Philip. I support adoption as well.
> 

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/