Subject: [dnsext] [Editorial Errata Reported] RFC6840 (4191)

From: RFC Errata System <[email-masked]>
Date: Tue, 2 Dec 2014 08:36:46 -0800 (PST)

The following errata report has been submitted for RFC6840,
"Clarifications and Implementation Notes for DNS Security (DNSSEC)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6840&eid=4191

--------------------------------------
Type: Editorial
Reported by: Edward Lewis <[email-masked]>

Section: 5.11

Original Text
-------------
...

A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  The
      zone MUST also be signed with each algorithm (though not each key)
      present in the DNSKEY RRset.  

Corrected Text
--------------
A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  Each
      authoritative RRset in the zone MUST be signed with each 
      algorithm (though not each key) present in the DNSKEY RRset.  

Notes
-----
Zones aren't signed (per se), the data sets within them are.  But not cut point (NS) and glue.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6840 (draft-ietf-dnsext-dnssec-bis-updates-20)
--------------------------------------
Title               : Clarifications and Implementation Notes for DNS Security (DNSSEC)
Publication Date    : February 2013
Author(s)           : S. Weiler, Ed., D. Blacka, Ed.
Category            : PROPOSED STANDARD
Source              : DNS Extensions
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 2 Dec 2014 12:10:19 -0500

While the new text is OK, I do not think the old text is wrong.
"signing a zone" is a well known term of art for signing the
authoritative RRsets in the zone.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Tue, Dec 2, 2014 at 11:36 AM, RFC Errata System
<[email-masked]> wrote:
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Brian Haberman <[email-masked]>
Date: Tue, 02 Dec 2014 15:21:19 -0500

Despite Donald's assertion, I think this is a valid erratum and should
be marked Verified.  However, I will wait for others to chime in on the
subject before doing so.

Regards,
Brian

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 2 Dec 2014 16:06:45 -0500

I agree the text Ed supplied is clearer to outsiders and has the same meaning to 
insiders as the original text. 
I recommend you approve the errata. 

Olafur

> On Dec 2, 2014, at 3:21 PM, Brian Haberman <[email-masked]> wrote:
>

---

From: Edward Lewis <[email-masked]>
Date: Tue, 2 Dec 2014 18:11:45 +0000

That may be - but there’s currently yet another call for a SIG(AXFR),
which to me is “signing the zone.”  When I was reading the RFC (just to
catch up) that was in the back of my mind.

FWIW, I have corrected anyone who says they 'sign the zone’. Partly
because that is not what is done in much of today’s operations - most of
the signing is incremental (a few sets at a time).  Implementations that
assume they can do batch-style signing of zones never survive the testing
phase (never the load test).

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 2 Dec 2014 16:11:57 -0500 (EST)

The errata is correct, but I agree with Donald - the old text is adequate 
and unlikely to lead to confusion.  (Well ... plenty of people are 
confused about this particular piece of the spec, but this clarification 
is unlikely to change that.  I am probably also biased, as the writer of 
that old text.)

I have no objection to marking this as verified, but I do not see it as 
necessary.

-- Sam

---

From: Warren Kumari <[email-masked]>
Date: Tue, 2 Dec 2014 16:29:03 -0500

On Tue, Dec 2, 2014 at 4:11 PM, Samuel Weiler <[email-masked]> wrote:
> and unlikely to lead to confusion.  (Well ... plenty of people are confused
> about this particular piece of the spec, but this clarification is unlikely
> to change that.  I am probably also biased, as the writer of that old text.)
>

I think it is not necessary. We have tools called things like
"dnssec-signzone", not "dnssec-sign_authorative_rrset".
While the amended text is technically correct (which is the best type
if correct), it isn't IMO necessary. But, I don't really care any more
than the effort required to write this mail, so whatever...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: manning bill <[email-masked]>
Date: Tue, 2 Dec 2014 13:28:29 -0800

concur with Donald & Sam.  

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 2December2014Tuesday, at 13:11, Samuel Weiler <[email-masked]> wrote:

> The errata is correct, but I agree with Donald - the old text is adequate and unlikely to lead to confusion.  (Well ... plenty of people are confused about this particular piece of the spec, but this clarification is unlikely to change that.  I am probably also biased, as the writer of that old text.)
> 
> I have no objection to marking this as verified, but I do not see it as necessary.
> 
> -- Sam
>

---

From: "Blacka, David" <[email-masked]>
Date: Tue, 2 Dec 2014 21:53:56 +0000

Agreed. 

Sent from my iPhone

> On Dec 2, 2014, at 4:12 PM, Samuel Weiler <[email-masked]> wrote:
>

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 3 Dec 2014 09:51:37 +0100

> be marked Verified.  However, I will wait for others to chime in on the

I see a few pros and cons; yes the proposed text is correct and better
than the original. However, this is not the only place that 'signing the
zone' is used, and used with the meaning 'signing each authoritative
RRset within the zone' in the set of RFC4033-4035 (and possibly outside
of those as well).

But I have had people ask me what 'signing the zone' actually means,
usually in the context of KSK vs ZSK (and hence, is the DNSKEY set part
of 'the zone'), not necesarily in the context of algorithm downgrade
protection.

Then again, RFC4033 actually defines a 'signed zone' as 'A zone whose
RRsets are signed and ...'. So while signing full zones in AXFRs might
add confusion here, I do think it is stated correctly as it is.

Then again (again), that is about whether there are signatures at all
and 'signed' there doesn't mention signed by what
(keys/algorithms/autographs).

So I don't think the errata is necessary, but I wouldn't exactly be
opposed either.

Jelte

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 03 Dec 2014 10:32:47 +0100

> than the effort required to write this mail, so whatever...

The DNS RFC are already plagued with a lot of fuzzy wordings leading
to confusion by non DNS experts.  Therefore it will be good to be
have this errata.

	jaap

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 3 Dec 2014 10:15:52 -0500

> to confusion by non DNS experts.  Therefore it will be good to be

I agree with Jaap.  This is such a minor step to take to increase the
precision of the wording, with seemingly no disagreement that the new
wording is deficient.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Dec 2014 08:37:53 -0800

> add confusion here, I do think it is stated correctly as it is.

Just to drive the point home a bit further, since you brought up the definition in RFC 4033:

   Signed Zone: A zone whose RRsets are signed and that contains
      properly constructed DNSKEY, Resource Record Signature (RRSIG),
      Next Secure (NSEC), and (optionally) DS records.

A developer asked me a few years ago "does that mean that all the RRsets are signed? What if just the A records are signed?" That's a valid question given the definition. It is only by reading the rest of the document do you get the feeling (but never the actual statement) that it means *all* of the RRsets in the zone.

--Paul Hoffman

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 03 Dec 2014 18:40:30 +0100

On 03-12-14 17:37, Paul Hoffman wrote:
>> I see a few pros and cons; yes the proposed text is correct and
>> better than the original. However, this is not the only place that
>> 'signing the zone' is used, and used with the meaning 'signing each
>> authoritative RRset within the zone' in the set of RFC4033-4035
>> (and possibly outside of those as well).
>> 
>> But I have had people ask me what 'signing the zone' actually
>> means, usually in the context of KSK vs ZSK (and hence, is the
>> DNSKEY set part of 'the zone'), not necesarily in the context of
>> algorithm downgrade protection.
>> 
>> Then again, RFC4033 actually defines a 'signed zone' as 'A zone
>> whose RRsets are signed and ...'. So while signing full zones in
>> AXFRs might add confusion here, I do think it is stated correctly
>> as it is.
> 
> properly constructed DNSKEY, Resource Record Signature (RRSIG), Next
> Secure (NSEC), and (optionally) DS records.
> 
> A developer asked me a few years ago "does that mean that all the
> RRsets are signed? What if just the A records are signed?" That's a
> valid question given the definition. It is only by reading the rest
> of the document do you get the feeling (but never the actual
> statement) that it means *all* of the RRsets in the zone.

It actually means all *authoritative* RRsets are signed. Glue and
occluded data for example are not signed.

The devil is in the details :)

- Matthijs

> 
> --Paul Hoffman _______________________________________________ dnsext
> mailing list [email-masked]