Subject: weiler-dnssec-dlv-02

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Mar 2007 13:41:16 +0100

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Sam, finally, I have read your document on DLV.

{I have carried it around in printed form for 1 week now.
 It has four pages of colouring on the backs... but in the end, I had to 
 surrender it to Liam permanently, so I had to use an electronic copy. }

>   DNSSEC trust anchors outside of the DNS delegation chain.  It allows
>   resolvers to validate DNSSEC-signed data from zones whose ancestors
>   either aren't signed or refuse to publish Delegation Signer (DS)
>   records for their children.

The word "ancestor" is certainly correct, but it just surprised me.
Do we use that word in other DNS documents to refer to a superior zone?

I think that the last sentence of the second paragraph of 2.:
  "Absence of a DLV..."

is important enough to warant a new paragraph, but also perhaps to be
said again elsewhere. Section 4 says something interesting that suggests
that when we discover the absence of a DLV, it means that we have
actually already found out if it was secured via another method.
You say it again in section 5 :-)

section 3 explains the mapping through several examples.
I think that the mapping should be explained a little bit more formally,
perhaps with a figure.

I suggest:

given:
  DLV configuration #1
  zone				DLV-server
  org.				trustbroker.example.com

=> DLV records for example.org are at:
		   example.trustbroker.example.com.

or given:
  DLV configuration #2
  zone				DLV-server
  .				bar.example.com

=> DLV records for example.org are at:
		   example.org.bar.example.com.

(I suggest you should show a third example with two DLV servers shown,
although this is really a local issue)

Pargraph 4 (page 4), needs to use figures/tables, or just needs to be
removed in favour of section 5. Is there a URL for INI1999-19?

Paragraph 3 of section 5, "   Having found the closest enclosing DLV RRset..."
can you seperate out each of the possible results as numbered points.

Would the rules in paragraph 2, section 6, not only a benefit to all
DNSSEC aware resolvers? section 9 tells me a bit more why not, maybe.

Section 7, my suggested figures should be trivially combined into a new
figure. 

page 7 (section 9), paragraph 3:

"  As a reminder, resolvers MUST NOT use the mere presence of an RRSIG
   or apex DNSKEY RRset as a trigger for doing validation, whether
   through the normal DNSSEC hierarchy or DLV.  Otherwise, an attacker
   might perpetrate a downgrade attack by stripping off those RRSIGs or
   DNSKEYs."

=> "As a reminder, resolvers MUST NOT use the absence of an RRSIG
   or apex DNSKEY RRset as an indication to avoid doing validation, whether
   through the normal DNSSEC hierarchy or DLV, as an attacker
   may perpetrate a downgrade attack by stripping off those RRSIGs or
   DNSKEYs."

Is IANA willing to comply to this request?

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

--
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: David Conrad <[email-masked]>
Date: Wed, 21 Mar 2007 20:29:30 -0700

Michael,

> Is IANA willing to comply to this request?

Sorry, which request?

Rgds,
-drc

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 22 Mar 2007 08:36:09 +0100

On Wed, Mar 21, 2007 at 08:29:30PM -0700,
 David Conrad <[email-masked]> wrote 

> >Is IANA willing to comply to this request?

Creating a DLV registry, as instructed in the IANA Considerations
section.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 22 Mar 2007 14:05:29 +0000

> Creating a DLV registry, as instructed in the IANA Considerations section.

if iana were to create dlv.iana.org and open it to all parties at no fee and
with heavy credential checking, world wide service and operations, auditing
for stale keys, and strong security around the KSK, then isc would have no
more reason to operate dlv.isc.org and we would throw our support behind iana.

---

From: David Conrad <[email-masked]>
Date: Thu, 22 Mar 2007 12:30:31 -0700

Hi,

>> Creating a DLV registry, as instructed in the IANA Considerations  

So, this raises interesting questions.

First, I don't think "dlv.iana.org" is the right place for something  
like this.  If it is to exist, it should be in .ARPA.

A more interesting bit is encompassed in what Paul stipulates:

> if iana were to create dlv.iana.org

IANA can, of course, create a registry that accepts information  
provided to it similarly to what we do for root zone management.

> open it to all parties

It would not be open to all parties.  As per the draft, it would only  
be open to TLD operators.

> at no fee

IANA is not permitted to charge fees.

> with heavy credential checking,

Nope.  The draft says we're to use our "own best practices" which I  
take to mean the same process we use to "authenticate" root zone  
change requests.

> world wide service and operations,

Nope. Not specified in the draft.

> auditing for stale keys,

Nope. Not specified in the draft.

> and strong security around the KSK,

Not specified in the draft, but define "strong".  IANA already has  
some level of security, but I suspect nothing on the order of what  
would be necessary to provide a sufficient level of assurance that  
the KSK wasn't compromised.  Since the data we're talking about here  
are used to sign information that relates to national interests, I  
suspect the level of security necessary is on the order of that  
necessary to protect national-level secrets.  I don't plan on moving  
IANA to a former ICBM silo.

In my mind, this sort of points out a bit of a flaw in the  
operational implications of DNSSEC.  Forget (as we have to date since  
it is a hard problem) how one might recover from a root KSK  
compromise.  Pragmatically speaking, the holder of the root KSK is  
setting itself up to be a teensy bit of a target.  Compromise of the  
root KSK would have ... significant implications and likely  
astounding liabilities.  Who wants that?  Since the implications are  
so great (and there is no way to recover), you have to be _EXTREMELY_  
careful with the key.  This level of care is likely to be is very,  
very expensive.  Who is going to pay for that?

However, to answer the question:

> Is IANA willing to comply to this request [to create a DLV  
> registry, as instructed in the IANA Considerations section]

IANA does what we are instructed to do by the IESG.

Rgds,
-drc

---

From: Alex Bligh <[email-masked]>
Date: Thu, 22 Mar 2007 20:10:19 +0000

--On 22 March 2007 12:30 -0700 David Conrad <[email-masked]> wrote:

> Pragmatically speaking, the holder of the root KSK is  setting itself up
> to be a teensy bit of a target.  Compromise of the  root KSK would have
> ... significant implications and likely  astounding liabilities.  Who
> wants that?

People seem to be happy fighting over who runs the non-DNSSEC equivalent.

(ducks & runs)

Alex

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 22 Mar 2007 18:35:27 -0500

David Conrad wrote:

> Not specified in the draft, but define "strong".  IANA already has  some 
> level of security, but I suspect nothing on the order of what  would be 
> necessary to provide a sufficient level of assurance that  the KSK 
> wasn't compromised.  Since the data we're talking about here  are used 
> to sign information that relates to national interests, I  suspect the 
> level of security necessary is on the order of that  necessary to 
> protect national-level secrets.  I don't plan on moving  IANA to a 
> former ICBM silo.
> 
> In my mind, this sort of points out a bit of a flaw in the  operational 
> implications of DNSSEC.  Forget (as we have to date since  it is a hard 
> problem) how one might recover from a root KSK  compromise.  
> wants that?  Since the implications are  so great (and there is no way 
> to recover), you have to be _EXTREMELY_  careful with the key.  This 
> level of care is likely to be is very,  very expensive.  Who is going to 
> pay for that?
> 

Thanks David for re-stating the requirement for emergency KSK rollover 
requirement.

However, the KSK security strength was not particularly stressed in the 
trust anchor (TA) automated rollover requirements draft that the DNSEXT 
produced, at least not with the above pragmatic perspective. The DNSEXT 
wg has moved this draft to the IESG, so it looks like a done deal for 
the wg.

In the early days of TA rollover requirements discussions, I used to 
advocate for the expliciteness of emergency rollover recovery 
principles, with an implied "catastrophic failure mode" disclosure 
requirement. I.e. let's disclose the exact circumstances where "there is 
no way to recover", so that _EXTREME_ _CARE_ could be applied to these 
circumstances.

But the wg paid more attention to other requirements and selection 
criteria. Overall, I came to the conclusion that the TA rollover issue 
hit a limit in what an IETF wg can realistically achieve.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: Joao Damas <[email-masked]>
Date: Thu, 22 Mar 2007 15:11:36 +0100

and hope IANA would take the entries already in dlv.isc.org into that  
registry, providing continuity.

Joao

---

From: [email-masked]
Date: Fri, 23 Mar 2007 00:38:52 +0000

and importing from another registry supports the requirement for
 "heavy credential checking" how?  Transitive Trust is a slippary
 slope.

--bill

---

From: Paul Vixie <[email-masked]>
Date: Fri, 23 Mar 2007 06:22:32 +0000

> So, this raises interesting questions.

yes.

> like this.  If it is to exist, it should be in .ARPA.

that'd be your call, of course.

> provided to it similarly to what we do for root zone management.

fine by me.

> be open to TLD operators.

ah, i missed that part.  that'd be a great start.  dlv.isc.org would mirror
the DLV RRs you put into dlv.arpa, assuming the signatures validated.  (there
would still be a need for non-TLD DLV RRs, so, isc would fill that need.)

> IANA is not permitted to charge fees.

kewl.

> take to mean the same process we use to "authenticate" root zone  

that's good enough.

> Nope. Not specified in the draft.

i suspect it's out of scope for this draft, but would appear elsewhere.

> Nope. Not specified in the draft.

this, too, is out of scope for this draft, but would appear elsewhere.

> necessary to provide a sufficient level of assurance that the KSK wasn't
> compromised.  Since the data we're talking about here are used to sign
> information that relates to national interests, I suspect the level of
> security necessary is on the order of that necessary to protect
> national-level secrets.  I don't plan on moving IANA to a former ICBM silo.

whatever security would be appropriate for the root zone KSK would be
perfectly adequate for a DLV registry KSK.  since you're going to have
to do the former at some point, i'm merely asking for the latter.

> problem) how one might recover from a root KSK compromise.  Pragmatically
> speaking, the holder of the root KSK is setting itself up to be a teensy bit
> of a target.

yes.

> Compromise of the root KSK would have ... significant implications and
> likely astounding liabilities.  Who wants that?

nobody *wants* it.  several of us are willing to *accept* it.  (incl. you?)

> Since the implications are so great (and there is no way to recover), you
> have to be _EXTREMELY_ careful with the key.  This level of care is likely
> to be is very, very expensive.  Who is going to pay for that?

i have heard more than one person say that icann has a lot of money these
days and that makes me presume that it can handle these operations.  if i'm
wrong then i'd expect an amendment to NTIA's IANA contract specifying larger
chunks of cash to cover these operations.  (or larger voluntary contributions
from ICANN's constituencies.)  but we are far afield from sam's draft, now.

> IANA does what we are instructed to do by the IESG.

even if it's an unfunded mandate like "operate a secure dlv registry" or
"sign the root zone and keep the root KSK secure enough for the whole world
to depend on it not being compromised" ?  or would you, at some point, tell
IESG "that's all fine and well, but who's going to pay for it all" ?

---

From: David Conrad <[email-masked]>
Date: Fri, 23 Mar 2007 01:08:47 -0700

Paul,

> that'd be your call, of course.

Well, no.  Not really.  IANA is just the technical administrator  
for .ARPA.  Name creation in that zone depends on IAB and/or IESG  
action.

> to do the former at some point, i'm merely asking for the latter.

If we do the former, then why would we need to do the latter?

> days and that makes me presume that it can handle these operations.

Not that much money.  And it isn't in IANA's budget.

> if i'm
> chunks of cash to cover these operations.

The NTIA IANA contract is $0.  The USG got out of paying for IANA a  
while ago.

> (or larger voluntary contributions from ICANN's constituencies.)

And they should fund this because?

> but we are far afield from sam's draft, now.

Yep.

> IESG "that's all fine and well, but who's going to pay for it all" ?

Speaking personally:

Historically, registry creation was essentially free: how much does  
it cost to create a file and make that file available on an existing  
network infrastructure?  My suspicion is that folks never really gave  
the cost of creating and maintaining registries much thought.  For  
example, I personally don't remember anyone talking about how  
expensive it would be to create and maintain the {IRIS,URI,URN}.ARPA  
domains and if they became popular or relied upon, it would probably  
be pretty expensive. And then there is the (unsigned) root of the  
DNS: how much do you think it costs the root operators to provide  
that service these days?  I'd bet your life the cost of providing  
that service wasn't considered when the DNS was being created.

Of course, the environment in which the Internet operates has changed  
a bit, so at some point, I suspect it may be necessary for ICANN and  
the IETF community to figure out how to fund and/or constrain the  
resource requirements RFCs can impose on IANA. Hasn't been necessary  
to date.  DLV is, perhaps, a wakeup call in that sense.

However, personal rambling aside and back to the question at hand: if  
the IESG directs IANA to create a DLV registry as the result of an  
independent submission draft and without full specification of how  
that registry should be created and operated, we'd propose something  
and if that didn't fly (which it undoubtedly wouldn't if people  
expect it to be secure and reliable), push back and request a revised  
IANA considerations section.

By the way, what would happen if the DLV registry key were to be  
compromised?

Rgds,
-drc

---

From: [email-masked]
Date: Fri, 23 Mar 2007 11:10:59 +0000

On Fri, Mar 23, 2007 at 10:45:49AM +0100, Joao Damas wrote:
> 
> On 23 Mar 2007, at 01:38, [email-masked] wrote:
> 
> True, however transitive mistrust flies well. So, your reply  
> indicates to me that I should not trust stuff coming from you. It  
> doesn't however mean there is no proper way of transferring the  
> entries subject of this discussion.
> 
> Joao

	i perceive either a misunderstanding or a failure to communicate.
	let me try again (although you have stated that there is no trust
	on your part for statements I make)

	if I, as the receiveing party, am to properly do credential checking,
	I will not trust the credential checking of the party from whom I
	receive the incoming dataset.  I will do it myself, using the "heavy"
	checking indicated above.  My customers would and shold expect no less.

	this in no way precludes "proper" transfer of the entries.  we now
	return you to the ISC/IANA business matters....

--bill

---

From: Paul Vixie <[email-masked]>
Date: Fri, 23 Mar 2007 13:56:20 +0000

> If we do the former, then why would we need to do the latter?

i'm presuming that if you did the former, noone would ask you to do the latter.

> And they should fund this because?

that depends.  either because it's good for the internet market to have some
security in dns, and signing the root is hard-for-whatever-reason so this is
a backstop measure.  or, because they'd rather not see ICANN take a large
amount of money from someone they fear (or loathe) under this excuse-umbrella.

or the funding wouldn't happen, and IANA would then have to refuse IESG's
request-- is that possible?  (is there precedent?)  and more importantly,
could this also happen with root KSK management and root zone signing?  (if
so, then we all need to stop treating root signing as inevitable, or we need
to treat funding as an issue right up there with policy and permission.)

> > "sign the root zone and keep the root KSK secure enough for the whole
> > world to depend on it not being compromised" ?  or would you, at some
> > point, tell IESG "that's all fine and well, but who's going to pay for it
> > all" ?
> 
> Speaking personally:
> 
> Historically, registry creation was essentially free: how much does it cost
> to create a file and make that file available on an existing network
> infrastructure?  My suspicion is that folks never really gave the cost of
> creating and maintaining registries much thought.  For example, I personally
> don't remember anyone talking about how expensive it would be to create and
> maintain the {IRIS,URI,URN}.ARPA domains and if they became popular or
> relied upon, it would probably be pretty expensive.

the old assumption was that USG would pay for it.
the new assumption is that ICANN will pay for it.
(it's possible that both assumptions were wrong.)

> And then there is the (unsigned) root of the DNS: how much do you think it
> costs the root operators to provide that service these days?  I'd bet your
> life the cost of providing that service wasn't considered when the DNS was
> being created.

funding of the infrastructure during the days when DNS was rolled out was an
NSFnet and/or DARPA thing.  i'll raise you your life that at least one USG
rootop has listed their root server as a funding priority in at least one
USG-paid budget during the last 30 years.

as to how much it costs _these_days_, i know that verisign recently announced
a USD $100M expansion of their infrastructure, and it probably includes more
than just their .COM servers.  i also know that most of ISC's costs for f-root
are underwritten by the community -- without extensive sponsorship we would
not have 40+ anycast instances.  my estimate of the dollar value of the
sponsored services is "really high, quite a lot, really."

> to date.  DLV is, perhaps, a wakeup call in that sense.

if that's so, then, root KSK handling and root zone signing would have been a
wakeup call of similar magnitude, and DLV's role as an early deployment aid
has been successful in at least one small way.

> By the way, what would happen if the DLV registry key were to be  

same as if the root KSK were compromised after the root zone is signed.
which is, it would become possible to substitute evil data and
cryptoauthenticate that evil data, such that anyone trusting the root KSK
(or DLV registry key) would potentially have high confidence in evil data.

---

From: David Conrad <[email-masked]>
Date: Fri, 23 Mar 2007 11:07:56 -0700

Paul,

On Mar 23, 2007, at 6:56 AM, Paul Vixie wrote:
> security in dns,

I'm pretty sure "for the good of the Internet" doesn't carry all that  
much weight anymore.  But then again, I'm a bit cynical.

> request-- is that possible?  (is there precedent?)

Good question.  I'm investigating.

Rgds,
-drc

---

From: Joao Damas <[email-masked]>
Date: Fri, 23 Mar 2007 13:44:52 +0100

On 23 Mar 2007, at 12:10, [email-masked] wrote:

> you have stated that there is no trust

not what I said.

> 	checking indicated above.  My customers would and shold expect no  

the credential verification process can be passed along with the  
entries. It really is not hard

Joao

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 27 Mar 2007 08:45:27 -0700

If you were to go that route a sensible first step would be to require the type of auditing currently required by CABFORUM for issuers of Extended Validation certificates.

The end entity authentication requirements would not be relevant but the rest of the document would.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Vixie
> Sent: Thursday, March 22, 2007 10:05 AM
> To: [email-masked]
> Subject: Re: weiler-dnssec-dlv-02 
> 
> if iana were to create dlv.iana.org and open it to all 
> parties at no fee and with heavy credential checking, world 
> wide service and operations, auditing for stale keys, and 
> strong security around the KSK, then isc would have no more 
> reason to operate dlv.isc.org and we would throw our support 
> behind iana.
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' 
> in a single line as the message text body.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 Mar 2007 17:56:11 +0200

>>>>> "David" == David Conrad <[email-masked]> writes:

    >> Is IANA willing to comply to this request?

    David> Sorry, which request?

10.  IANA Considerations

   IANA is asked to create a DLV registry targeting the root and
   containing DLV records for TLDs that ask to have DLV records
   published for their own zones.  IANA is instructed to use its own
   best practices for authenticating TLD operators' requests to insert,
   modify, and delete DLV entries.  This DLV registry MUST itself be
   signed with DNSSEC.  IANA may use its own discretion to choose a
   suitable domain name at which to publish this registry; dlv.iana.org
   is suggested.

   To be clear, IANA is only being asked to publish DLV records for top
   level domains, thereby taking advantage of the IANA's existing
   relationships with the TLD operators and established procedures for
   authenticating requests from the TLD operators.

   DLV makes use of the DLV resource record previously assigned by IANA.