Re: [dnsext] TALINK RRTYPE review. Start of three week comment period

[Edward Lewis <[e-mail]>]

I have an extreme distaste for this proposal.

RRSIG includes inception and expiration times to limit the window of 
opportunity for replay attacks as well as the lack of a revocation 
mechanism in DNSSEC.  They shouldn't be ignored at all, when a spec 
says "Ignore date changes in the RRSIG" there ought to be a security 
impact analysis attached.

The draft does not address the security issue of PFS 
(http://en.wikipedia.org/wiki/Perfect_forward_secrecy).  I am 
concerned that if (say) a 3-year old KSK is finally "broken", it can 
be used to construct a new KSK chain to a false key.

Maintaining a history of keys re-balances of key management in 
DNSSEC.  If a KSK is effective for one year, it only has to meet the 
strength requirements for a year.  If it will be used "forever" to 
lead through a chain of keys to the current key, the original KSK has 
to be stronger.  For example, NIST is recommending 80 bits of 
strength until 2011 or so (in some cases) but 112 bits after that for 
some time.  Keeping the KSK around in a history means 80 bits is no 
good even now.  And then there's the issue of key disposal.

The NIST recommendations I refer to are highlighted here:
http://csrc.nist.gov/groups/ST/key_mgmt/documents/June09_Presentations/Elaine_Barker_Transitions_KMWS_June2009.pdf
(to the best of my understanding).

If a KSK is in use for 2010 it can be managed for a one-year 
effectivity.  If there's history involved, we switch gears so that 
the KSK has an eternal effectivity.

Given my uneasiness with the reason for the record type, I am against 
allocating a position in the registry.

At 14:46 +0200 7/22/09, [e-mail] wrote:
>Dear colleagues,
>
>I have been assigned with the task of coordinating an expert-review of the
>DNS RRTYPE parameter allocation for TALINK, present in
>http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-00 .
>
>Attached is a completed template requesting an RRTYPE assignment under the
>procedures of draft-ietf-dnsext-2929bis.
>
>This request will be evaluated by expert review.  This mail initiates a
>three week comment period on the RRTYPE request.  If you have comments on
>the request, please post them to this list.
>
>Kind regards,
>
>Roy Arends
>
>
>---
>
>
>
>Template from http://tools.ietf.org/html/rfc5395
>
>
>
>DNS RRTYPE PARAMETER ALLOCATION TEMPLATE
>
>
>A.    Submission Date:
>       30, June 2009
>
>B.    Submission Type:
>       [X] New RRTYPE
>       [ ] Modification to existing RRTYPE
>
>C.    Contact Information for submitter:
>       Name: Wouter Wijngaards
>       Email Address: [e-mail]
>       International telephone number: [phone]
>       Other contact handles: -
>       (Note: This information will be publicly posted.)
>
>D.    Motivation for the new RRTYPE application?
>       Please keep this part at a high level to inform the Expert and
>       reviewers about uses of the RRTYPE.  Remember most reviewers
>       will be DNS experts that may have limited knowledge of your
>       application space.
>
>A double linked list of names that contain specific DNSKEY data at
>those names.  The type is to be used by applications that maintain trust
>anchors for DNS validators.  The DNSKEY data is used to rollover trust
>anchors to the current key.  Therefore they must know the start and end
>of the list, and be able to move forwards and backwards through the list.
>
>E.    Description of the proposed RR type.
>       This description can be provided in-line in the template, as an
>       attachment, or with a publicly available URL:
>
>The RR is a data type, can be handled as an RFC3597 unknown record.
>No additional section processing.
>
>The rdata is two domain names, presentation format is the two
>domain names, wireformat the two domain names in uncompressed form.
>
>The type is used to link domain names.
>TALINK _start_ _end_ for the list head and
>TALINK _prev_ _next_ for linking the elements.
>To end the list, the root label '.' is used to denote the endpoints.
>
>Thus, the root can be the list head, but not a list element.
>This is fine, saves space and is less complex than other solutions
>for flagging list endpoints or an empty list.
>
>F.    What existing RRTYPE or RRTYPEs come closest to filling that
>       need and why are they unsatisfactory?
>
>RP has two domain names but it means 'Responsible Person'.
>MINFO has two domain names but means 'Machine Information'.
>These types are compressed, which is nice.
>
>The PTR type is the right concept, but has only one domain
>name in its rdata, and I need two.  If I use two PTRs then
>the validator cannot distinguish the previous and next pointer,
>because the ordering of RRs in an RRset is not fixed.
>
>Another alternative is using PTR records at _start, _end, _prev and
>_next prefixes for disambiguation.  Prefixes limit the domains that
>can be used because of the max domain name length.  This is
>the alternative I would consider if this application is denied.
>
>G.    What mnemonic is requested for the new RRTYPE (optional)?
>       Note: This can be left blank and the mnemonic decided after the
>       template is accepted.
>
>TALINK (Trust Anchor LINK).
>
>H.    Does the requested RRTYPE make use of any existing IANA
>       Registry or require the creation of a new IANA sub-registry in
>       DNS Parameters?
>       If so, please indicate which registry is to be used or created.
>       If a new sub-registry is needed, specify the allocation policy
>       for it and its initial contents.  Also include what the
>       modification procedures will be.
>
>No.
>
>I.    Does the proposal require/expect any changes in DNS
>       servers/resolvers that prevent the new type from being
>       processed as an unknown RRTYPE (see [RFC3597])?
>
>no changes.
>
>J.    Comments:
>
>-
>
>
>--
>to unsubscribe send a message to [e-mail] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/namedroppers/>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at [phone]

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.