Subject: [DNSOP] Some comments on draft-hoffman-dns-terminology

From: Matthijs Mekking <[email-masked]>
Date: Wed, 01 Apr 2015 10:02:02 +0200

Hi wg,

I have reviewed the DNS terminology draft and have some comments.

1.
In section 3 (DNS Message Format) the last three paragraphs discusses 
"default TTL", Glue records and Referrals. I wonder if that belongs in 
the section about DNS Message Format. To me it sounds like it is more 
suitable to be put in the Resource Records section or Zones section.

2.
On page 7, about Priming: typo: resolvrer -> resolver.

3.
On page 8, Slave is described. We also know this commonly as a 
Secondary. The same applies for Master (just one below), it is also 
referred to as Primary (However, then this may become confusing with the 
term below that: Primary Master).

4.
On page 12, about NSEC: It would be nice to add a line on what NSEC does:

    NSEC -- Section 3.2 of RFC 4033 has this to say on the subject of
    NSEC: "The NSEC record allows a security-aware resolver to
    authenticate a negative reply for either name or type non-existence
    with the same mechanisms used to authenticate other DNS replies."
    In short, The NSEC record was introduced to provide authenticated
    denial of existence.

    The NSEC resource record lists two separate things: the next
    owner name (in the canonical ordering of the zone) that contains
    authoritative data or a delegation point NS RRset, and the set of RR
    types present at the NSEC RR's owner name.  (Quoted from Section 4 of
    4034)

5.
On page 12, about NSEC3: I think it is valuable to add one or two lines 
about the why of NSEC3:

    NSEC3 -- The NSEC3 record also provides authenticated denial of
    existence and, in addition, mitigates against zone enumeration (or
    "zone walking") and supports Opt-Out. The NSEC3 resource record
    looks quite different than the NSEC resource record.  NSEC3 resource
    records are defined in [RFC5155].

6.
Should we also define zone enumeration?

7.
On page 13 KSK and ZSK are described. There is also a notion of a 
Combined Signing Key (CSK) [1]. In RFC 6781 this is called a Single-Type 
Signing Scheme: "In cases where the differentiation between the KSK and 
ZSK is not made, i.e., where keys have the role of both KSK and ZSK, we 
talk about a Single-Type Signing Scheme." Would it be worth to add this 
term to this document?

Best regards,
   Matthijs

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Apr 2015 11:46:08 -0700

On Apr 1, 2015, at 1:02 AM, Matthijs Mekking <[email-masked]> wrote:
> In section 3 (DNS Message Format) the last three paragraphs discusses "default TTL", Glue records and Referrals. I wonder if that belongs in the section about DNS Message Format. To me it sounds like it is more suitable to be put in the Resource Records section or Zones section.

Good point. TTL should be in "Resource Records", and Referral/Glue should be in Zones.

> On page 7, about Priming: typo: resolvrer -> resolver.

Fixed.

> On page 8, Slave is described. We also know this commonly as a Secondary. The same applies for Master (just one below), it is also referred to as Primary (However, then this may become confusing with the term below that: Primary Master).

I added the synonym for slave. How do people feel about "primary" and "master"?

>   types present at the NSEC RR's owner name.  (Quoted from Section 4 of

Great!

> On page 12, about NSEC3: I think it is valuable to add one or two lines about the why of NSEC3:
> 

Ditto!

> Should we also define zone enumeration?

Only if we agree on a definition. Proposal?

> On page 13 KSK and ZSK are described. There is also a notion of a Combined Signing Key (CSK) [1]. In RFC 6781 this is called a Single-Type Signing Scheme: "In cases where the differentiation between the KSK and ZSK is not made, i.e., where keys have the role of both KSK and ZSK, we talk about a Single-Type Signing Scheme." Would it be worth to add this term to this document?

That seems to be a very new term, maybe premature for this document.

--Paul Hoffman

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 02 Apr 2015 09:32:35 +0200

Paul,

On 04/01/2015 08:46 PM, Paul Hoffman wrote:
>> In section 3 (DNS Message Format) the last three paragraphs
>> discusses "default TTL", Glue records and Referrals. I wonder if
>> that belongs in the section about DNS Message Format. To me it
>> sounds like it is more suitable to be put in the Resource Records
>> section or Zones section.
>

Actually I think $DEFAULT_TTL should be in Zones too as it only exists
in zone files.

[SNIP]

> Only if we agree on a definition. Proposal?

Perhaps we can quote RFC5155 here:

    Zone enumeration is enabled by the set of NSEC records that exists
    inside a signed zone.  An NSEC record lists two names that are
    ordered canonically, in order to show that nothing exists between the
    two names.  The complete set of NSEC records lists all the names in a
    zone.  It is trivial to enumerate the content of a zone by querying
    for names that do not exist.

>> Combined Signing Key (CSK) [1]. In RFC 6781 this is called a
>> Single-Type Signing Scheme: "In cases where the differentiation
>> between the KSK and ZSK is not made, i.e., where keys have the role
>> of both KSK and ZSK, we talk about a Single-Type Signing Scheme."
>> Would it be worth to add this term to this document?
>

I disagree: We have been talking about this in DNSOP for years, also
referred to as Combined Signing Key (CSK).

I think it is important that people who read this terminology realize
that a key can be a KSK and ZSK at the same time. Think of a key as an
actor and Key-signing and Zone-signing as roles: An actor can have
multiple roles.

I can be talked into not adding this term to this document but then I
would like to see one additional line, something like:

     The roles KSK and ZSK are not mutually exclusive: A single key
     can be both KSK and ZSK at the same time.

Best regards,
   Matthijs

>
> --Paul Hoffman _______________________________________________ DNSOP
> mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Apr 2015 07:13:47 -0700

> Actually I think $DEFAULT_TTL should be in Zones too as it only exists

This does not seem to be a commonly used term, does it?

>   for names that do not exist.

Yeah, I realized that after I sent the message last night, and already put it in the pre-draft. I tweaked a bit because we have definitions for NSEC and NSEC3 as well, and now the considerations from NSEC5.

> referred to as Combined Signing Key (CSK).

The term "combined signing key" doesn't appear in any RFC, and "CSK" only appears once, in RFC 5155 as part of a octet string. :-)

> that a key can be a KSK and ZSK at the same time.

Fully agree.

> Think of a key as an

That seems fine. If either CSK or Single-Type Signing Scheme become more common terms, we can add them to an updated RFC.

--Paul Hoffman

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 03 Apr 2015 11:39:35 +0200

Paul,

On 04/02/2015 04:13 PM, Paul Hoffman wrote:
>> Actually I think $DEFAULT_TTL should be in Zones too as it only
>> exists in zone files.

Sorry I meant $TTL here from RFC 2308. My point is that it is something
that can be set in zone files, so "default ttl" should be in the section
about Zones.

>> ordered canonically, in order to show that nothing exists between
>> the two names.  The complete set of NSEC records lists all the
>> names in a zone.  It is trivial to enumerate the content of a zone
>> by querying for names that do not exist.
>
> Yeah, I realized that after I sent the message last night, and
> already put it in the pre-draft. I tweaked a bit because we have
> definitions for NSEC and NSEC3 as well, and now the considerations
> from NSEC5.
>
>
>>>> On page 13 KSK and ZSK are described. There is also a notion of
>>>> a Combined Signing Key (CSK) [1]. In RFC 6781 this is called a
>>>> Single-Type Signing Scheme: "In cases where the
>>>> differentiation between the KSK and ZSK is not made, i.e.,
>>>> where keys have the role of both KSK and ZSK, we talk about a
>>>> Single-Type Signing Scheme." Would it be worth to add this term
>>>> to this document?
>>>
>> I disagree: We have been talking about this in DNSOP for years,
>> also referred to as Combined Signing Key (CSK).
>
> The term "combined signing key" doesn't appear in any RFC, and "CSK"
> only appears once, in RFC 5155 as part of a octet string. :-)
>
>> I think it is important that people who read this terminology
>> realize that a key can be a KSK and ZSK at the same time.
>
> Fully agree.
>
>> Think of a key as an actor and Key-signing and Zone-signing as
>> roles: An actor can have multiple roles.
>>
>> I can be talked into not adding this term to this document but then
>> I would like to see one additional line, something like:
>>
>> The roles KSK and ZSK are not mutually exclusive: A single key can
>> be both KSK and ZSK at the same time.
>
> That seems fine. If either CSK or Single-Type Signing Scheme become
> more common terms, we can add them to an updated RFC.

Fair enough.

Best regards,
   Matthijs