Subject: [dnsop] EPP & DNSSEC; TTL's for DS records

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Dec 2004 13:38:44 -0500

This covers a lunch time discussion about whether EPP ought to 
include a TTL in the request to add a DS record.  (No offense to 
those who want DNSKEY - that's a different issue.)  Before launching 
into the specifics of the TTL of the DS RR, here's a preamble about 
the issue with respect to the NS RR - which has been known for some 
time but little discussed.  It's here to set context.

It has been long known that TTL's of delegation points sometimes 
don't work out as planned.  By this I refer to the fact that if an 
iterative resolver seeks the address of www.example.net with nothing 
in the cache, it will first receive a referral from "." to "net." 
with the "."'s version of the "net." NS set.  Asking a "net." server 
will give you a referral to "example.net." personified by the 
"example.net." NS set in the authority.

What's missing here is the iterative server's ever receiving the 
authoritative NS set for "net."  Even though the copy of the "net." 
NS set is more credible (RFC 2181) when obtained from the child than 
when obtained from the parent, if the iterating server never sees the 
child's, the parent copy (and the parent TTL) is what is used.

Fortunately when the query cited above proceeds, the answer will 
likely have the AAAA record in the answer section and the 
"example.net." NS set in the authority section.  In this case, the 
latter copy is more credible than the "hint" given by the "net." 
servers and will usurp the position in the cache.  (Unless the 
"example.net." name server uses minimal responses - meaning that only 
the answer section is filled in.  This option is implementation 
specific, for those that keep track of such things.)

This preamble is meant to lay a context of why a few of us sat to 
talk about the importance (or not) of including a TTL parameter in an 
EPP command to add or modify a DS record.  (Looking at it, maybe it's 
not an important context, but it's what floats in the back of our 
minds - some of us anyway.)

Keep in mind that, unlike the NS set the preamble worried about, the 
DS set is authoritative in the parent zone and is not even in the 
child zone.  This makes the parent's setting of the TTL more 
interesting.  Or not.

So, here goes.  The question is "should a DS request in EPP also 
allow the child to dictate to (or just ask) the parent the TTL?"

There are pro's, con's, and other considerations.

The "pro" is that the shorter a TTL is, the quicker a child can 
change the SEP key.  A smooth transition ought to be wary of the 
persistence of DNS data, like images on a phosphorus CRT, which 
limits DNS's ability to turn on a, um, coin.

The "con" is that the TTL is a design consideration when setting up a 
DNS constellation.  The shorter a TTL is, the stronger the 
authoritative service must be.  A short TTL means caching will be 
bypassed more often.

If the EPP client (ultimately equivalent to the child zone operator) 
wants to really mess with the the EPP server organization's DNS 
constellation, a TTL of 1 second is set.  This will cause a lot more 
traffic to hit the parent than if the TTL was for 48 hours given the 
same work load.

There's the issue of whether this matters at all.  A DS set with a 
high TTL does not mean that an abuser of the DNSKEYs can extend the 
length of an attack.  The child zone can always have a short validity 
period on the RRSIG covering the DNSKEY set, limiting the usefulness 
of the overly long TTL'd DS.  The risk to the child of high TTL'd DS 
sets is, in reality - err - theory as we haven't set this up, a 
longer "mean time to recovery" because of the persistence (a la 
phosphorus) issue.

So, would it be beneficial for EPP to include the TTL?  (I doubt that 
I've sufficiently covered the issue - I'm leaving the opportunity for 
others to chime in with points, kind of as a "gift of the season.")

As far as the apparent risk that a child can select an abusively low 
TTL, the parent can have a "business rule" setting the lower limit of 
the TTL to a certain number.  Encoding a business rule per se would 
be a bad, bad thing in the protocol definition.  But recommending 
that a registry adopt such a business rule ought to be in the 
security considerations section.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield
.
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: Wed, 22 Dec 2004 07:56:43 +0100

Edward Lewis wrote:

> sets is, in reality - err - theory as we haven't set this up, a longer 
> "mean time to recovery" because of the persistence (a la phosphorus) 
> issue.
>

If the abuse above is "key compromise" then the RRSIG over the DNSKEY 
can be made with the compromised key and the RRSIG validity over the DS 
is what counts. What is, I think most important is that the child can 
signal the validity interval of the RRSIG over the DS RR.  (we say 
something about that in draft-ietf-dnsop-dnssec-operational-practices, 
new version by the end of this week).

The TTL acts as damage control parameter. Although it does not safeguard 
in the case of attacks the short TTL does help in cases of for instance 
private key loss, where the DS needs to disapear from the DNS ASAP.

But short TTLs and short sig validity intervalls increase the cost on 
the operations. More queries, more frequent signing.  If you allow EPP 
to sign tailored TTLs and signature validitiy intervalls you could be 
able distinguish service and thereby destinguish by valuable Euros.

> the TTL to a certain number.  Encoding a business rule per se would be 
> a bad, bad thing in the protocol definition.  But recommending that a 
> registry adopt such a business rule ought to be in the security 
> considerations section.

Why would encoding business rules be bad, normally business rules go by 
the name of local policy, don;'t they?

My 2 cents (pick a currency of more or less value:-)

-- Olaf

.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 22 Dec 2004 10:14:19 -0500

At 7:56 +0100 12/22/04, Olaf M. Kolkman wrote:

>If the abuse [above] is "key compromise" then the RRSIG over the DNSKEY can be
>made with the compromised key and the RRSIG validity over the DS is what
>counts. What is, I think most important is that the child can signal the
>validity interval of the RRSIG over the DS RR.  (we say something about that
>in draft-ietf-dnsop-dnssec-operational-practices, new version by the end of
>this week).

True, if the private key has been exposed/discovered then the a false 
RRSIG(DNSKEY) can be floating around.  This puts the limiting 
temporal factor on the RRSIG(DS) and the TTL offered by the parent.

In -epp-secdns- there is a validity interval (vInterval) which is a 
topic of a documentation issue (meaning, the words aren't clear). 
vInterval is a length of time (I believe in seconds) to use for the 
RRSIG's expiration time, as in "start time + vInterval".  (That's 
what the doc means, three folks reading it got three different 
meanings - hence the doc issue.)  So, the draft already recognizes 
the need to be careful of the RRSIG validity period.  Well, I think 
the situation is handled (even if I was one of the readers that got 
this wrong from an initial reading. ;) )

>The TTL acts as damage control parameter. Although it does not safeguard in
>the case of attacks the short TTL does help in cases of for instance private
>key loss, where the DS needs to disapear from the DNS ASAP.

I don't agree with that, that the TTL isn't meant to protect against 
damage.  The TTL represents a tradeoff of persistence versus 
performance.  What the TTL limits is incoherence of data.

Perhaps sometime someone ought to write a document to clarify the 
relationship of TTL and DNSSEC.

(That's a joke.)

Remember, TTL's are not fool proof, so I wouldn't hold them up as an 
agent of security.  A cache might get a signed RRSet with a maximum 
TTL of 900 seconds and decide to never decrement it on answer.  The 
cache could give out the 900 second TTL up until the end of the 
RRSIG's validity period.  (And beyond too - but a wary recipient 
would disregard the answer.)

Short TTL's do help lower mean time to repair.

When considering the TTL of the DS, it's a trade of cost and benefit. 
In this case the benefit is to one party (child) and the cost is to a 
different party (parent).  (Assuming a canonical EPP setting.)

>But short TTLs and short sig validity intervalls increase the cost on the
>operations. More queries, more frequent signing.  If you allow EPP to sign
>tailored TTLs and signature validitiy intervalls you could be able distinguish
>service and thereby destinguish by valuable Euros.

Well, the appropriate terminology is "allow[ing] EPP to express a 
requested TTL" for this issue.  EPP is only the expression of the 
request, not the processing of the request.

EPP commands don't necessarily launch an operation such as signing. 
In the conceptual model for EPP/DNSSEC, there is a database and other 
elements in between the EPP server and the DNS signer.  If a 1000 EPP 
commands are received in 11 minutes to add DS's, the DNS signer may 
still run just once if the registry's policy is 11 minute updates to 
the DNS.

The TTL isn't an issue for this part of the operations.  The TTL is 
an issue for the DNS servers (not the signer even).  If I'm adding 
records every 11 minutes, I'm signing then - not a function of the 
TTL.  Hopefully, the vInternval will be at least 660 seconds too.

(If 11 seems like an oddly particular number, it's because I wanted 
to use an oddly particular number in the example.)

>Why would encoding business rules be bad, normally business rules go 
>by the >name of local policy, don;'t they?

The issue here is a mix of (protocol development) environments.  In 
DNSSEC, "local policy" dictates how  a validator goes about it's 
work.  I.e., what crypto algorithms to use, the sequence of 
operations, etc.

Business rules in the EPP sense don't impact the representation, 
parsing, transfer, etc., of the EPP protocol.  E.g., perhaps the 
.example registry will not allow you to register names with vowels or 
digits in them.

The desire is for a registrar to be able to do business with .example 
and with .bert (which is "famously liberal" in what it accepts so 
long as enough Euros are attached).  If the desire is to allow the 
registrar to use the same EPP client software to provision names from 
.example and from .bert, then the EPP protocol elements ought not 
have the no vowels nor digits rule in them.

Like the 11 minute example above, this may drive a registry to say 
that vInternval must be at least 1320 seconds, or maybe 3600 seconds, 
or maybe a number based on a price paid for the name.  The TTL might 
be given a lower limit of an hour and an upper limit of 1 week - 
these numbers might be adjusted when engineering a DNS constellation 
to meet a service level agreement.

As an aside, limiting TTL from being too high might be a way to 
prevent a person from buying a name for 3 months and then hoping to 
reap benefits by having healthy caches hold the name for a year.  Not 
a realistic threat - as one popular DNS implementation caps all TTL's 
at one week anyway - certainly not economically useful, but maybe 
useful to hide from whois/iris exposure.

---

From: David Blacka <[email-masked]>
Date: Wed, 22 Dec 2004 12:24:25 -0500

Edward Lewis wrote:
> This covers a lunch time discussion about whether EPP ought to include a 
> TTL in the request to add a DS record.  (No offense to those who want 
> DNSKEY - that's a different issue.)  Before launching into the specifics 
> of the TTL of the DS RR, here's a preamble about the issue with respect 
> to the NS RR - which has been known for some time but little discussed.  
> It's here to set context.

I am of two minds about this issue as well.

On one hand, the DS is the parent's data, and thus is allowed to set the 
TTL to whatever it wants.

On the other hand, the child has a vested interest in the length of the 
TTL because it factors into the time-to-recover from a SEP key compromise.

One one hand, the DNSSEC documents say this (protocol-09, section 2.4):

    The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
    (that is, the NS RRset from the same zone containing the DS RRset).

On the other hand, I'm not sure that this advice makes much sense.

-- 
David Blacka    <[email-masked]>
Sr. Engineer    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: Wed, 22 Dec 2004 13:06:18 -0500

At 12:24 -0500 12/22/04, David Blacka wrote:

>On one hand, the DS is the parent's data, and thus is allowed to set the TTL
>to whatever it wants.
>
>On the other hand, the child has a vested interest in the length of the TTL
>because it factors into the time-to-recover from a SEP key compromise.
>

Your fourth hand's comment is quite interesting.  The delegating NS 
RRset would be replaced in the cache by the delegated NS RRset per 
the credibility rules of RFC 2181 in a "normal" case today.

I (would) have to look to see where in the DNS protocol *documents* 
it is stated that a server MUST/SHOULD/MAY put the authoritative 
server set in the authority section.  Given that one implementation 
has this as a configurable option, I assume that the inclusion is not 
mandated in definition.  In which case, the recommendation the third 
hand points to would make sense.

I think we could spend many cycles trying to figure out that the Good 
RFCs mean in this case.  (We've done so before on many topics.) 
Given that this is an M&O Area group, I'd like to get to what makes 
operational sense, even with the points your first two hands 
illustrate.

I'd propose this addition to the -epp-secdns-:

The addition of TTL as a mandatory to implement facet of a DS record 
element, optionally filled in.  In the security extensions section 
urge adopters of this extension to seriously consider setting up 
business rules limiting the range of TTL values accepted to counter 
potential "subscriber fraud" situations.

This is a *sketchy* proposal...comments are desired.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: David Blacka <[email-masked]>
Date: Wed, 22 Dec 2004 13:38:37 -0500

Edward Lewis wrote:
> RRset would be replaced in the cache by the delegated NS RRset per the 
> credibility rules of RFC 2181 in a "normal" case today.

Yes, that is what I was referring to.

> element, optionally filled in.  In the security extensions section urge 
> adopters of this extension to seriously consider setting up business 
> rules limiting the range of TTL values accepted to counter potential 
> "subscriber fraud" situations.
> 

It seems perfectly reasonable to have the desired TTL be optionally 
transmitted via EPP.

It is completely unreasonable to demand that the registry must pay 
attention to this value.

So, as long as it is clear that the transmitted TTL is a desire, a hint 
if you will, that may be ignored, I think we are where we need to be.

Actual advice to registries (parents, really) on what they should 
reasonably do with this data would be nice.  Pointing out that they 
might not want to accept *any* value, like you suggest, is a good start.

Of course, if the actual best advice is to set the DS TTL to the NS TTL, 
then we may have a situation where the desired TTL is transmitted via 
EPP, and always ignored.  Just trying to be helpful ;)

---

From: Rob Austein <[email-masked]>
Date: Thu, 23 Dec 2004 01:12:18 -0500

<hat chair=off just-another-bozo=on>

  Last time I remember this coming up, my tentitive conclusion (no
  longer recall whether I convinced anybody else) was that EPP should
  include a mechanism to let the EPP client specify a desired TTL, but
  that this was advisory, and that the EPP server shouldn't be
  required to honor it.  I'm using the terms "EPP client" and "EPP
  server" loosely, just to indicate the roles.

  The general idea here is that, if the parent zone admin has no
  strong opinion on what the TTL should be and the child zone admin
  does, there ought to be a way for the child zone admin to inform the
  parent zone admin of the child zone admin's wishes.  However, since
  the DS RR is data in the parent zone, the child zone admin's
  opinions are purely advisory and the parent zone admin wins if the
  parent zone admin has a strong opinion.  YMMV.

</hat>
.