Hello to the list,
Nice piece of work !
Some remarks - nothing spectacular :
1) Last sentence in the first paragraph - Introduction
(about :
"no direct relation between ... and validating caching name servers.")
Isn't this sentence superfluous ? I fail to see where a possible
relation would indeed change something to these guidelines.
But by including the sentence about no relationship,
one starts to wonder if something escapes me ...
2) Double Signature ZSK rollover in 4.1.1.3
The last sentence states there are three steps.
I think this is an error :
There are three states, yes;
but there are only two manipulations to perform.
(to me it seems logical to interpret "step" as :
"operation to perform")
3) 4.1.3 Difference between ZSK and KSK rollovers
4.3.3 Security Lameness
(actually, 4.1.3 introduces another way of KSK rollover.
In that respect the title of the section is confusing !)
In 4.1.3 the text suggest to publish a DS record in the parent
for which there is no DNSKEY record in the child zone.
In 4.3.3 the text suggest the parent could verify that
the DNSKEY is actually published by the child.
--> 4.3.3 could explicitly state that, if a parent performs
this kind of checking, then the "double DS method"
of 4.1.3 is not possible.
Furthermore :
as registry (for .eu) we think that it is important to assist
our registrars in setting DNSSEC up correctly.
Consequently, we do verification when a registrar sends us
DNSSEC information. So we cannot distinguish between
a DNS Operator that performs double DS KSK rollover and
an operator making a mistake ...
4) 4.3.4 DS Signature Validity Period
The last paragraph holds a sentence that states :
"Shortening the TTL reduces the damage of a successful replay attack."
I don't think this is correct (or relevant).
For me, the chances for a replay attack increase with the signature
validity period, not with the value of the TTL.
The value of the paragraph lays, for me, in the propagation of updated
DS RRsets (cfr the presentation on low TTL's, last week).
5) 4.4.2.1 Maximum value (for Signature Validation Period)
I think this paragraph should make a reference to Key Rollover !
Motivation : no matter how long a signature is valid,
in order for it to be used, the corresponding Key must be available.
(so : if the reason for long RRSIG validity is not to recalculate them,
then ...)
I do admit that none of the Key Rollover scenario's take into
account the signature validity time (but the TTL).
And indeed, nothing prevents to generate a signature, valid for 1 year,
with TTL of 1 day, and perform key rollover every three months :
the still valid signature simply times out of the cache,
to be replaced by a new one, valid for a new year.
Kind regards,
Marc Lampo
EURid (for .eu)
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: 30 March 2012 11:36 AM
To: [email protected]
Cc: [email protected]
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Domain Name System Operations
Working Group of the IETF.
Title : DNSSEC Operational Practices, Version 2
Author(s) : Olaf M. Kolkman
W. (Matthijs) Mekking
Filename : draft-ietf-dnsop-rfc4641bis-10.txt
Pages : 78
Date : 2012-03-30
This document describes a set of practices for operating the DNS with
security extensions (DNSSEC). The target audience is zone
administrators deploying DNSSEC.
The document discusses operational aspects of using keys and
signatures in the DNS. It discusses issues of key generation, key
storage, signature generation, key rollover, and related policies.
This document obsoletes RFC 4641 as it covers more operational ground
and gives more up-to-date requirements with respect to key sizes and
the DNSSEC operations.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
