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

["W.C.A. Wijngaards" <[e-mail]>]

Hi Ed,

This is about the (dnsop) draft more than the TALINK type, but I'll 
respond to your criticism here.

On 07/22/2009 04:16 PM, Edward Lewis wrote:
> I have an extreme distaste for this proposal.

ok

> 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.

Well the analysis is this
* The data is not claimed to be 'current' despite the expiration.
It is claimed to be historical.  Therefore, current data still has
to obey the inception and expiration dates.
* The DNSKEY data is still a valid statement.
It says that at that particular date, KSK1 signed KSK2 in
the rollover process.  That statement, once it has been made,
is indeed a timeless fact.  It happened, and the rollover has
been done.
* So to rephrase the previous point: history is a truth.  Saying
that something happened in the past is a correct statement.  It is
not a security problem.  In fact given the public nature of the DNS
this was publicly visible to everyone (in the past).
* So the expiration date is not applicable for someone trying
to follow what the rollover scheme has been.  What is applicable
is KSK1 signed KSK2, KSK2 signed KSK3, ...

* As a sidenote, 5011 of MofN did not allow a rollover to be
un-done.  There is no undo for DNSSEC rollover.  Hence repeating
and observation MUST have been part of the correct rollover.

> 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.

So what?  You are citing short periods, for say SSL keys very long
lifetimes are apparantly possible.

If someone breaks a 3year old KSK, it could only be used on someone
who is using that 3year old KSK.  (Again, for SSL certificates,
aparrantely 10-years is fine for 2048bit keys).

So, it boils down to you having a dislike because the 'control'
over how long a DNSKEY remains valid goes from the publisher to
the validator ?  It is that validator that according to the
draft can opt to say that '3 years is too much, I will not do
historical key rollover'.

> 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

Well, the publisher cannot force it, but the validator user can
configure locally that he thinks - say - that 1024 bit keys can
only be trusted for 2 years at most.  And he has his own clock
and nobody can tell him otherwise.

> 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.

Well no problem private keys can be deleted just fine.
This just tracks history, what happened.

Of course, if you are distributing trust anchors and your rollover is
once per year and you use 80 bits, well then you cannot support 
end-users perhaps.  If you think people with 3 year old keys should be
able to use your service securely, you should choose keys that stay
secure for 3 years?   Am I missing something in your argument here?

>
> 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.

Again, the choice for how long a KSK is effective is in the validators
hands.  This (could be) configured.  The zone operator, yes, has to
publish.  Because, say, some end user may make a different analysis
of the lifetime of that key than you do.  And of his risks, say, some
low risk organisation may think a key that is older is sufficient
(since even if the key is very very old, the algorithm I give
turns into a leap of faith).  And a high risk organisation could put
a maximum lifetime in that validator for the trust anchor
(and really high risk organisations are always online right? so they do 
not need it and only need 5011).

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

That reasoning makes sense.  But I do not agree with the arguments
you give against the reason for the record type.

Best regards,
    Wouter


>
> 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.


--
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/>