On Oct 7, 2022, at 10:46 AM, Roy Arends <r...@dnss.ec> wrote:
>
>
>
>> On 7 Oct 2022, at 17:21, Paul Wouters <p...@nohats.ca> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
