Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt

[Paul Hoffman <[e-mail]>]

On Oct 7, 2022, at 10:46 AM, Roy Arends <[e-mail]> wrote:
> 
> 
> 
>> On 7 Oct 2022, at 17:21, Paul Wouters <[e-mail]> wrote:
>> 
>> On Fri, 7 Oct 2022, Paul Hoffman wrote:
>> 
>>> On Monday, I'll do a new draft with:
>>> 
>>> What we today call "DNSSEC" is the DNSSEC specification defined in {{RFC4033}}, {{RFC4034}}, and {{RFC4035}}.
>>> However, earlier incarnations of DNSSEC were thinly deployed and significantly less
>>> visible than the current DNSSEC specification.
>> 
>> "s/and significantly less visible than the current DNSSEC specification/was never deployed beyond early adopter testing domains
>> as it had no method of linking parent and child zones securely"
> 
> The last (added) part is not correct. RFC2535 had a way of linking parent and child zones securely (chaining, see RFC2535 6.3). It was suboptimal, and an effort was initiated by NLNetLabs (Ted, Jaap, Miek at the time) to get “sig at parent” instead of “sig at child” (see [1]). This eventually lead to the creation of the DS record and the concept of zone- and key signing keys. 
> 
> Jakob Schlyter (Jakob’s Bug [2]) discovered that validating resolvers that read NXT record containing a DS bit, but not the KEY bit would treat delegations as not secure, despite the DS record being present, making the DS concept incompatible with RFC2535. This is why NXT SIG and KEY became NSEC, RRSIG and DNSKEY. 
> 
>> Wording could be changed, but the point is, it could never be
>> "production deployments" as it required hardcoded keys to build
>> a path of trust.
>> 
>> Perhaps even:
>> 
>> DNSSEC documents predating {{RFC4033}}, {{RFC4034}}, and {{RFC4035}}
>> specify obsoleted DNS RRtypes that never saw deployment beyond early
>> adopter testing, and haven't been deployed in nearly two decades,
>> and are of no concern to implementers.
> 
> This is not correct. SIG and KEY have not been obsoleted and have been in use for SIG(0). But I digress.
> 
> Perhaps:
> 
> What we refer to as "DNSSEC" is the third iteration of the DNSSEC specification; [RFC2065] being the first, [RFC2535] being the second. Earlier iterations have not been deployed on a significant scale. Throughout this document, "DNSSEC" means the protocol initially defined in [RFC4033], [RFC4034], and  [RFC4035].

I like Roy's text more than PaulW's two suggestions. Saying things like "never" seems tricky. Naming the iterations seems good too.

--Paul Hoffman