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

From: [email-masked]
Date: Wed, 22 Jul 2009 14:46:21 +0200

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: [email-masked]
      International telephone number: +31 20 888 4551
      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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Wed, 22 Jul 2009 10:16:41 -0400

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.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

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

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 22 Jul 2009 18:23:16 +0200

Hi Ed,

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

> I have an extreme distaste for this proposal.

ok

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

> (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?

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

> 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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Jul 2009 10:11:56 +1000

People who have published keys today expect that validators that
are turned on in three years time with old keys to FAIL to validate
using them.  This changes this expectation retroactively.

I can remember having discussions like this years ago.  Keeping the
chain of trust forever was not a good idea then and it still isn't
now.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 22 Jul 2009 20:30:14 -0700

Mark and all,

  I recall as well.  From my perspective and if memory serves me
right, there really was no "Chain of Trust" and really isn't now.
I also doubt that a "Chain of Trust" will be fully established or
solidify at any point in time.  Governments may be an exception.

> chain of trust forever was not a good idea then and it still isn't

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Jul 2009 12:03:17 +1000

> solidify at any point in time.  Governments may be an exception.

This proposal creates chains of trust through time.

Once a key is rolled it should not be used for any further cryptographic
operations.  It should be treated as if the private part of the key
has been exposed.  The only cryptographic operation that should be
done with a rolled key is to revoke itself.

Mark

---

From: bert hubert <[email-masked]>
Date: Thu, 23 Jul 2009 08:05:04 +0200

forgot to CC the list.

---------- Forwarded message ----------
From: bert hubert <[email-masked]>
Date: Thu, Jul 23, 2009 at 8:04 AM
Subject: Re: [dnsext] TALINK RRTYPE review. Start of three week comment period
To: [email-masked]

> http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-00 .

I have read this, and I think I understand what it says. Here goes. So
we have a trust anchor, which is hardcoded in the configuration file.

However, a rollover has occurred, and we didn't see it happen, so we
could not update our trust anchor.
(Just wondering, does this currently happen already in validating
resolvers? I got the impression trust anchors were rather static.)

Now the validator is back in business, possibly because it was only
turned on for the first time after being installed on the PC in the
factory from a 2 year old master, and it finds it can't validate
anything based on the trust anchor it has, because it has since rolled
over.

However, it finds a chain described by TALINK records which say 'this
key is my successor, and I've signed it using the anchor you know,
please trust it'.

And things are good.

Is this description correct? If so, how can we be sure that the
original anchor (which may have been rolled over because it was
compromised), cant' be "resurrected" by a third party using an
appropriate TALINK chain?
In other words, doesn't TALINK negate the utility of doing KSK
rollovers in the first place?

Also, DNSSEC is already straining with complexity - I know for sure
since I started implementing it for a prototype on
www.powerdnssec.org. I wonder if we shouldn't simply tell people to do
this kind of thing out of band. Say, using 'windows update'.

On the TALINK record per se, if it turns out that having a
'rolled-over key' resurrection ability is a good idea, we surely need
a "TALINK" rrtype.

          Bert

---

From: Alex Bligh <[email-masked]>
Date: Thu, 23 Jul 2009 07:34:03 +0100

> could not update our trust anchor.
...
> key is my successor, and I've signed it using the anchor you know,
...
> rollovers in the first place?
...
> I wonder if we shouldn't simply tell people to do

I agree. I think for similar reasons it fails where there
are other reasons for the rollover (e.g. algorithmic
weakness). I'm struggling to think of any scenario where
you would go to the effort of rolling keys, but want the
old ones to remain valid for future signings.

Moreover, in Bert's use case at least, the two year old
PC is going to need to have the /code/ for its DNSSEC
validator updated, as in the two year period which elapsed
since the factory master was made, the usual selection
of horrible bugs and algorithmic weaknesses will be found.
There needs to be a mechanism of doing this securely (probably
not using DNSSEC), and whatever it is can also update the
trust anchor.

-- 
Alex Bligh

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 23 Jul 2009 09:09:43 +0200

Hi Mark,

> using them.  This changes this expectation retroactively.

Well, if the zone owner wants to support it, then he can set
his expectations.  Otherwise, people can already do this?

> chain of trust forever was not a good idea then and it still isn't

Can you tell me why it was considered not a good idea?

It is of course not 'forever', but until the time that the
validator thinks the key can be trusted for.

Best regards,
   Wouter

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 23 Jul 2009 10:26:17 +0200

Hi Alex, Bert,

>> Is this description correct? If so, how can we be sure that the

Yes

>> rollovers in the first place?

That is a very good point.  The best way to stop someone putting
the rollover sequence in reverse is to look at the RRSIG dates.
The middle (of inception, expiration), must then increase over
time.  Therefore the TALINK chain is going forwards.

>> this kind of thing out of band. Say, using 'windows update'.

Well, because of the TALINK type the discussion seems to be
in dnsext, but I really put this draft to dnsop, as an aid
to validator configuration.  Which is outside of the DNSSEC
protocol.

> are other reasons for the rollover (e.g. algorithmic

Can you explain the failure with algorithmic weaknesses?

> old ones to remain valid for future signings.

Because most people are online 'pretty often', if you roll
once per year, then most people will use your latest trust
anchor.  With exceptions, for software out of boxes, ...

> not using DNSSEC), and whatever it is can also update the

So, is it allowed to have an alternative to this 'windows update' ?

Not everything has 'windows update'. Vendor dependence.
ServicePackN may not work. Not all software can be updated
(devices, livecd). You assume the update is secure.

Best regards,
   Wouter

---

From: bert hubert <[email-masked]>
Date: Thu, 23 Jul 2009 11:21:53 +0200

> (devices, livecd). You assume the update is secure.

We have to assume the update is secure, because such updates will also
typically install new revisions of the software. If we can't trust the
authenticity of the software update, who cares about the keying
material?

I know of no major OS that does not implement signed updates.

And of course we can solve this problem in DNSSEC too - but I'm
reminded of Scotty in Star Trek "Captain, I cannot give her any more
or she'll blow!".

    Bert

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 24 Jul 2009 11:56:43 -0400

>this kind of thing out of band. Say, using 'windows update'.

There are two cases to consider here.
One the root key I'm quite sure we can figure out a way to get that
key into OS-update distributions.

For keys lower in the tree inside tld's that are not signed I'm
not sure any OS vendor wants to put these keys into their updates.

For them TAR's and Trust history are the only viable options to
tell validator about the changed keys. (of course not rolling keys will
also help).

         Olafur

PS: do not forget about the Wireless router/withDNSSEC that you found in
your closet and you need to power up because the one you have been using for
the last 3 years died.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Jul 2009 12:44:23 -0400

Dear colleagues,

Without wishing to discourage the substantive comments being made  
about TALINK, I thought it might be a good idea to remind ourselves  
that the RRTYPE request is being handled according to our expert  
review procedures.  It's important therefore if you have objections to  
note the cases where they are especially relevant to the expert review  
rules, as opposed to more general objections to the technique.  Many  
messages have already made the distinction, but I just want to be  
certain everyone understands ways different kinds of feedback affect  
the expert's evaluation.

Andrew (as panel of experts chair)

Andrew Sullivan
[email-masked]