Subject: Re: [dnsop] EPP-DNSSEC Document Updates

From: Mark Kosters <[email-masked]>
Date: Thu, 3 Mar 2005 17:30:35 -0500

On Mon, Jan 24, 2005 at 05:57:32PM -0500, Samuel Weiler wrote:
> Section 2.1.2: It's still not clear exactly how the <secDNS:infData>
> element's sDate, eDate and vInterval should be used: in particular,
> none of these seem to specify a desired RRSIG lifetime.  Perhaps sDate
> and eDate are intended to do that, though it's likely that a DNSKEY
> will be in use for far longer than the requested signing interval --
> perhaps another field <maxRRSIGlifetime> is needed?  This way a client
> could say: don't publish this DS until time X, use an RRSIG lifetime
> no more than 3 days, resigning the DSset every day, and quit
> publishing this DS after 30 days.

By my reading:

 sDate means not being put in zone before it is that time
 eDate means taking it out of zone (preferably minus the eDate
   minus lifetime of the parent RRSIG).
 RRSIG lifetime, if honored, is supposed to be governed the
   signature interval that the client desires (ie only have signature
   valid for 4 days at a time as it moves between sDate and eDate).

Does that make sense?

Mark
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 3 Mar 2005 17:45:40 -0500

> -----Original Message-----
> From: Mark Kosters [mailto:[email-masked]] 
> Sent: Thursday, March 03, 2005 5:31 PM
> To: Samuel Weiler
> Cc: [email-masked]; Scott Hollenbeck
> Subject: Re: [dnsop] EPP-DNSSEC Document Updates
> 

Mark: are you suggesting that what's currently in there now as vInterval
more correctly identifies the RRSIG lifetime?

-Scott-

.

---

From: Mark Kosters <[email-masked]>
Date: Thu, 3 Mar 2005 18:04:25 -0500

> more correctly identifies the RRSIG lifetime?

I'm not sure it is needed as it seems a bit redundant to me. Sam
please correctly if I'm wrong.

Mark

-- 

Mark Kosters            [email-masked]       Verisign Applied Research
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Mar 2005 08:07:10 -0500

>I'm not sure it is needed as it seems a bit redundant to me.

I have thought about the date and interval features a bit.  I have 
growing concerns in two contexts about whether these are beneficial 
in EPP.

In the context of the DNSSEC protocol, I think that the security 
parameters of one zone should not be linked to the parameters in 
another zone.  This is a long standing opinion of mine, dating back 
to when we (folks in design teams 2-3 years ago) talked about 
"trimming" the TTL's based on signature lifetimes.

In this case, the signature validity period of the DS RRSet is 
something that should be wholly determined by the parent.  The 
validity period is a measure of the faith in the protection of the 
private key.  The TTL on the DS RRSet is not a security parameter, 
but rather a measure of the persistence of the data.

An aside: that is why I don't violently oppose trimming a TTL of a 
RRSet to the end of the validity period of it's own RRSIG.  I may 
even agree to the trimming within the zone, e.g., the DNSKEY 
validity, but not beyond that.

This may seem to give too much power to the parent.  But recall that 
the child signs the DNSKEY RRSet.  There was a time at which I felt 
that the DNSKEY RRSIG was unnecessary for a one-key (i.e., KSK and 
ZSK are the same key) zone.  After some discussion, the DNSKEY RRSIG, 
which in this case may be just a self-signed signature, provided its 
own validity period.

E.g., looking at a parent/child...

In the parent:

          delegation.example.     NS      ns1.delegation.example.
                                  NS      ns2.delegation.example.
                                  DS      <refers to key #1>
                                  RRSIG   DS from March 1 to March 31
                                  NSEC    <next name>
                                  RRSIG   NSEC ...

In the child:

          delegation.example.     SOA     <soa stuff>
                                  RRSIG   SOA
                                  NS      ns1.delegation.example.
                                  NS      ns2.delegation.example.
                                  RRSIG   NS
                                  DNSKEY  <key #1>
                                  RRSIG   DNSKEY from March 7 to March 14

What is important to keep in mind is that the signature validity is 
supposed to be only a measure of the goodness of the product of the 
private (signing) key and not a measure of the validity of the data 
protected.  Don't be tempted to think of signature dates as a means 
to judge how fresh data is, or if one set of data is fresher than the 
next.

Even though the signature by the parent is good for the whole month, 
what it points to may only be good for the 8 days shown.  That's the 
"safety belt" worn by the child.

What I didn't include above is the TTL.  It's possible that a cache 
somewhere will accept, verify, and decide to hold on to the parent's 
DS record for X seconds.  During the passing of the X seconds, the 
child may change it's DNSKEY RRSet, and assuming the cache no longer 
has the DNSKEY RRSet, let's say the cache gets a another (can't 
really say newer) one.

At this point the cache may not be able to cleanly verify data, if 
the new DNSKEY RRSet contains no keys that are referred to in the DS 
RRSet.

At this point I need to ask these questions: Is this a problem of the 
validity period or TTL?  Or is it a problem with the 
validity-checking algorithm?

It could be either, that's why I am asking.  I don't really think it 
is the signature validity, but it could be the TTL.  Trimming the TTL 
on the DS RRSet to the DNSKEY RRSet might be worthwhile - with a lot 
of caveats.  Should this trimming be done at the parent or at the 
cache?

I don't think you want to have too much trimming at the parent 
because of the child.  One of DNS's strengths is it's loosey-goosey 
(yeah, I said it) management scheme.  DNS tolerates mismatches in NS 
RRSets, etc.  DNS "only" hints down, unless you take the indication 
of lameness as an upward referral.  While DNSSEC was plagued by a 
weak delegation point interface, scaling DNS has benefited from it.

This is why I resist a lot of efforts to make the parent base it's 
parameters on the child.  I don't want there to be a "feedback loop" 
effect.

Of course, the parent has to set delegation parameters according to 
the child's wishes - like the contents of the NS RRSet and DSRRSet. 
Those are matters for the registration activity.  But matters of zone 
security fall into issues like name server management, etc., i.e., 
infrastructural concerns.  I'm not of the opinion that we want to 
open this up too much to the child's meddling.

 From the context of a registry operator, accepting the dates that a 
DS RRSet is to be valid is proposition that I think needs some 
thought.  Not that I wouldn't want to offer this beneficial service, 
but it's not something that is currently in line with registry 
practices.

There is only one kind of date information held concerning an object, 
that being it's lifetime.  (Created, last modified, expires, billing, 
grace period, etc., all relate to the object's life time.)  Off hand 
I don't know of any other registry that holds data about the future 
of an object - just what's there now.  I.e., the name servers 
attached to an object are assumed to be current, etc.

Now, I understand that there is a difference between business rules 
and what's in EPP.  That may be part of my concern here.  But I'd 
like to examine whether it makes sense for a registry to even collect 
the validity period data.

Is there a registry willing to add to it's database a schema for 
"these are future edits to make to the registration?"  Would the 
schema be capped at the expiration of the object?  Would the schema's 
contents be altered automatically upon a renewal, an automatic 
renewal?  How would a registrant(or registrar) get access to this 
future information?  A special IRIS interface?

Besides the debate of implementing this new interface, the concern I 
have is garbage collection - once data's validity passes, is it 
forgotten?  Will it have to be logged incase of forensic activity?

And then there's the "feedback concern" - what happens if a 
registrant submits a new DS RRSet for June, but in May is acquired in 
a merger and things like keys, etc., are forgotten?  Can we be sure 
that the registrant will stay in synchronization with their plans?

Thinking like this makes me think that we ought to treat the DS RRSet 
just like the NS RRSet.  OTOH, the NS RRSet is authoritative at the 
child, the DS RRSet authoritative at the parent.  Nevertheless, I 
begin to question the utility of the validity periods (and resigning 
frequency).  The TTL problem?  I would need to see some impirical 
evidence of whether the parent ought to be mindful of the child's 
desires (inspire of the feedback look concern) or whether the issue 
ought to be built into the validation algorithm.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Achieving total enlightenment has taught me that ignorance is bliss.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Sat, 05 Mar 2005 16:19:57 -0500

Edward Lewis wrote:

> another zone.

(...)

> private key.  

I do agree with the general notion of chinese walls between child and 
parents but I'm picking on this particular point.

The signature validity interval over the DS is also a measure of faith 
in the protection of the private key _of_the_child. The security 
parameters of the child and parent are linked. Off course a parent could 
not care about its children but I'd think I'd allow for being more or 
less protecive for some of my children.

--Olaf

.

---

From: Edward Lewis <[email-masked]>
Date: Sun, 6 Mar 2005 15:06:27 -0600

For anyone reading this in detail...if you find a point to disagree 
on, let's hammer out that before continuing on.  I apologize for a 
rambling nature, this is more of trying explore a path with a lot of 
degrees of freedom and not really drawing a solid conclusion.

At 16:19 -0500 3/5/05, Olaf M. Kolkman wrote:
>I do agree with the general notion of chinese walls between child and parents
>but I'm picking on this particular point.
>
>The signature validity interval over the DS is also a measure of faith in the
>protection of the private key _of_the_child. The security parameters of the
>child and parent are linked. Off course a parent could not care about its
>children but I'd think I'd allow for being more or less protecive for some of
>my children.

Having a brief conversation with Olaf last night, I think there is a 
question to ask here, but not necessarily in line with the words 
above.

As in - there's a replay problem with long-signed DS RRSets, but I 
don't think that the RRSIG(DS) validity is a measure of faith in the 
protection of the private key.  And, it's not that a parent registry 
could not care less about the children, but rather that it would be 
untenable to do so.

That aside, the problem lies in the situation in which a child's 
private key is guessed, exposed, or otherwise compromised resulting 
in the ability of an unauthorized agent to generate signatures that 
can be verified with the child's public key.  (Note - if the key is 
"lost" then it is no good to anybody.)

We need to solve for the case in which a child has just one DNSKEY 
record in the DNSKEY RRSet.  This simplifies the discussion and 
fortunately, it captures the worst case scenario.

Here's what could happen:

1) The parent signs the DS RRSet for March 1 to March 31.
2) The child signs the DNSKEY RRSet for March 7 to March 10.
3) On March 8, the child realizes that someone is generating malicious sigs.
4) The child removes the DNSKEY RRSet from their zone, perhaps replacing it.
5) The child requests the parent remove or replace the DS RRSet.
6) Optimistically, the parent pulls this within seconds.
    (Realistically, this will take longer.  But if it happens in seconds,
     we've captured the worst case scenario even more acutely.)

Now at this time, a resolver can't get access to the now worthless 
key through official channels (i.e., authoritative servers and caches 
that aren't being duped).

However, since the problem is that the child key is available to a 
malicious party, there is a step 7, 8, 9,...

7) The unauthorized agent can now sign a new copy of the DNSKEY 
RRSet, as well as other parts of the zone.  The new DNSKEY RRSIG 
could go until March 31.
8) The unauthorized agent can use this to get caches still holding 
the parent's DS RRSet [(step #1)] to authenticate false data.
9) The unauthorized agent can attempt to push the parent's DS RRSet 
to caches to prolong the agony beyond the TTL setting of the DS RRSet.

The "root" of the trouble is a lack of an explicit revocation 
mechanism in DNSSEC.  (Not a complaint, just an observation.)

What can be done to limit the impact of such an attack?

One is to request that the parent change/roll it's keys - so that the 
DS RRSet will not validate beyond the TTL life.  This would mean that 
the parent would have to resign everything in the zone (or at least 
what has been signed with the same key as has signed the DS RRSet in 
question).

That solution is heavyweight on the wrong party.  It also means that 
the brunt of the fix is borne by a larger community (all delegations 
are hit).  And finally, it opens up the registry to subscriber fraud 
via "crying wolf."

Taking a breath to look at what's in the message, I realize that I am 
not talking about something EPP specific, yet EPP is the impetus for 
the thread.  This is still a DNSSEC operations problem to solve - and 
eventually we need to get EPP to support this.

With that in mind, what are the goals?

1) Lacking an explicit revocation mechanism (and it won't happen), 
DNSSEC relies on the validity period to end the effectiveness of a 
signature.  Ergo, the shorter the validity period, the shorter the 
window of vulnerability of an abuse of the signature.

2) Generation of a signature imposes a noticeable computational cost, 
so there's a natural desire to want to delay signing unchanged data 
"again."  I.e., lengthen the signature validity.

Goals 1 and 2 are diametrically opposed.  This makes finding a 
natural and self-regulating setting quite hard.  In most cases, 
(i.e., not the DS RRSet) the beneficiary of #1 and #2 are the same 
entity (the zone administrator), but when it comes to the DS RRSet, 
the beneficiaries are not (registrant benefits more by shortening, 
registry benefits by lengthening).

After speaking with Olaf again, he and I both have the same thought 
at this point.   "The market should decide" the duration of the 
signature validity span.  (This is open to debate.)  I've been trying 
to think of someway to link the "optimal" validity span to some other 
parameter, but I don't think there's a wise choice.  (I.e., linking 
it to the zone minumum ttl from the SOA probably ain't wise.)

To bring this back to EPP and the document at hand, the question is 
whether the protocol needs to contain data to support this.

I'm pretty much sold that EPP should carry a requested TTL from the 
client to server (begging the question of whether or not the server 
heeds this).  I'm also nearly sold on the need for a "suggested max 
length of a validity interval."  That's two items, less than (and 
different) from the current set of "TTL, vInterval, startDate, and 
endDate."

vInterval isn't the same as the suggested max validity interval.  The 
former was a request to regenerate the signature (I think).  The 
latter is a limit on how long the RRSIG is to last.  I'd resist the 
temptation to make the validity duration be the same as the TTL.

Ordinarily, I'd feel that the child should not dictate what's in the 
parent zone.  The exception here is because of the exceptional case 
of the DS RRSet - the only set that is only authoritative when coming 
from outside the "rightful" zone.  (NSEC is in both.)

Having the suggestions for TTL and for the max validity interval does 
not mean that the business rules of the registry-registrar 
(server-client) have to heed them - in fact, error return codes are 
being built in to alert the client that the requests are not heeded.

For example, it's possible that a registrant may pay $10 per year for 
a name but has to live with 2 week signing intervals, but for $15 can 
get 1 week signing intervals.  (All of this is absurd, but used to 
illustrate a point.)  For $10 per year, suggesting a validity period 
of 10 days will be denied.  For $5 per year more, the same request 
would be honored.  I mention this example to illustrate the 
difference between what's the protocol and what is done in business 
rules.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Sun, 6 Mar 2005 16:34:26 -0600

At 17:13 -0500 3/6/05, Eric Brunner-Williams in Portland Maine wrote:
>How is this different from the registry publishing its dcp when the
>session begins, and the registrar and registry doing session setup and
>teardown until they agree on the dcp?

For one, it's not in the greeting. ;)

The above scenario assumes that the business rules regarding what's 
in a zone are set or negotiated off-line and only the requested 
maximum signing interval is contained in the protocol.  Whether the 
registry decides to heed the request is binary and the decision is 
returned in the response.  If the denial is because the registrant 
hasn't paid for "extra" service, well, that's not expressed in the 
response code.

Off hand, I forget if we've proposed that the denial of such a 
request is just a warning or a failure.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Sun, 6 Mar 2005 17:41:20 -0600

At 17:52 -0500 3/6/05, Eric Brunner-Williams in Portland Maine wrote:

>in epp we chose not to provide an in-session mechanism for negotiation.
>we did discuss negotiatian via setup/teardown till agreement or exhaustion.
>
>but independent of the session semantics, there is the client claim of
>binding policy on the server, just as there was with "privacy".

You're note did make me think of this.  One factor is that privacy is 
a lot more complicated than timing issues with DNSSEC data.  And 
privacy is a lot more contentious.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 06 Mar 2005 17:52:18 -0500

> For one, it's not in the greeting. ;)

the server asserts policy a.
the client asserts policy b.

since i don't have an interest this is just a note in passing, and i'll
go back to lurking.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 06 Mar 2005 18:52:40 -0500

> You're note did make me think of this.

that was why i wrote.

>                                         One factor is that privacy is

nope. just a policy glob.

> privacy is a lot more contentious.

empty calories.
.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 06 Mar 2005 17:13:47 -0500

---

From: "Niall O'Reilly" <[email-masked]>
Date: Tue, 08 Mar 2005 09:16:47 +0000

> future information?  A special IRIS interface?

As I read this, it seems you think this is a big deal.  I'm not sure 
that it is.

Conceptually, this is akin to what my bank already lets me do with 
"Internet
banking" by posting future transactions (for example, a fund transfer 
close
to the due date, rather than immediately the statement arrives).  They 
put
the request in a queue, provide me with an interface to display (but not
change) it, and take action when the due date arrives.

How they cope if I close my account, or merge it with another before 
the due
date, I have no idea. 8-)

If the banks can do it, I sure a clueful registrar could manage ...

Best regards,

Niall O'Reilly
University College Dublin Computing Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Mar 2005 09:01:29 -0600

At 9:16 +0000 3/8/05, Niall O'Reilly wrote:
>>  Is there a registry willing to add to it's database a schema for "these
>>are future edits to make to the registration?"  Would the schema be capped
>>at the expiration of the object?  Would the schema's contents be altered
>>automatically upon a renewal, an automatic renewal?  How would a registrant
>>(or registrar) get access to this future information?  A special IRIS
>>interface?
>
>As I read this, it seems you think this is a big deal.  I'm not sure that
>it is.

Why do you draw such a conclusion?  It's just a list of questions 
pertaining to one aspect holding future keys.

>Conceptually, this is akin to what my bank already lets me do with "Internet
>banking" by posting future transactions (for example, a fund transfer close
>to the due date, rather than immediately the statement arrives).  They put
>How they cope if I close my account, or merge it with another before the due

There is a large difference between a registry and a bank.

Some would argue that if a registry would try to perform services 
like this, it would be a manifestation of "feature creep" resulting 
in a cost borne by the customers of the registry and a possible 
albatross (an asset which comes back to haunt you later).

I'm not sure that, even awash in cash (resources) and looking to 
creep features, storing keys for future benefit would be a worthy 
feature to add.  Do you want to build operational dependencies 
between the DNS operator and registry any finer than we have now? 
Than is *needed* for DNSSEC?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar