Subject: Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance

From: Paul Wouters <[email-masked]>
Date: Fri, 1 May 2009 17:15:26 -0400 (EDT)

On Thu, 23 Apr 2009, Joe Abley wrote:

[ enabling DNSSEC from stale install media that has an old trust anchor ]

> I don't like the idea of incorporating magic numbers (e.g. "nine months") 
> algorithmically when trying to determine suitability of an old trust anchor.

I don't like it either, but currently, I don't see how to avoid this. The
problem might not be as severe, since when installing a new machine and
getting updates, one would think the newly installed machine is not using
itself as a resolver, since we only enable dnssec on resolvers now, not
on every install (yet).

But once every install gets dnssec, one reboot would do it. But perhaps
that can be caught with the "firstboot" feature of Fedora (I'm sure Ubuntu
has similar features)

> But it seems like a bad idea to package trust anchors administered by others 
> with any piece of software, if there's a chance that those trust anchors are 
> going to form a circular dependency in the process of updating them.

Circular dependancies are very common in the OS building/shipping model.

Paul

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 04 May 2009 16:45:06 -0700

I'll pass on my comments on the draft.  I've removed my comments that
were duplicates of those submitted by Ed and Paul W. 

I'm not an English language expert (even though it is my first and
primary language; I just defer to those with better knowledge than I),
but I did find the draft well readable and only spotted a few minor
typographical nits which makes it a pretty good document in my view.

Section 2, Last paragraph
------------------------------
  This text sort of implies implementations can pick which size of a
  hash they wish to support.  I'm not sure that was the intent or not.
  IMHO, implementations should only allow complete DS record length
  hashes (which may themselves be truncated versions of the hash
  algorithm).  Implementations SHOULD NOT allow for configuration of
  hash lengths which are shorter than what the DS length itself
  specifies.  DS lengths are frequently chosen with great care for
  cryptographic reasons.  I wouldn't be happy with an implementation
  that accepted a 2 byte hash as an acceptable truncated DS record.

Section 3, next sentence after step 4 
----------------------------------------
  - Doesn't take into account (5011) revoked keys.  It's discussed
    later, but this sentence is incorrect.  5011 REVOKED keys aren't
    caught as an exception in the above points and specifically prohibit
    "can be used authenticate RRSets at or below the trust anchor".

Section 3, next sentence after step 4 
----------------------------------------
  - used authenticate -> used to authenticate

section 4, "Trust anchors correspond to zones' key signing keys "
--------------------------------------------------------
  As has sort of been beat upon already, this isn't the case.  TAs can
  be either ZSKs or KSKs.

section 4
---------------------------------------------------------------------
 "updating that information" -> "update that information" 

section 4 and trust anchor repositories
-------------------------------------------------------------
  Section 4 is remiss in not mentioning obtaining keys via a third party
  trust-anchor-repository.  The "Trusted update mechanism" or "Manual
  configuration" should probably explicitly mention keys obtained from
  TARs because they're looking to be popular.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 5 May 2009 10:01:42 +0800

Dear all,
   I have a question which may not relate with the WGLC of this document.

  where is the validating resolver?

 it usally locates in the local host as the same as the normal resolver? or it usually locates in recursiver name server or some special host?
if it usally locates in the local host as the same as the normal resolver, every machine must be configured at leat one trust anchor. so the local machine need a lot of computing resources to finish the resolving process.

if  it usually locates in recursiver name server or some special host, the local host just send a query to that machine. if so, the data transfered between the local lost and the resolver is not secured, we need another mechanism to secure the data transfer.

Yao Jiankang

---

From: David Conrad <[email-masked]>
Date: Mon, 4 May 2009 19:08:51 -0700

On May 4, 2009, at 7:01 PM, YAO Jiankang wrote:
> it usally locates in the local host as the same as the normal  
> resolver? or it usually locates in recursiver name server or some  
> special host?

Today, it usually doesn't exist.  When it does, it is usually located  
on a recursive server used by multiple hosts.

> if it usally locates in the local host as the same as the normal  
> resolver, every machine must be configured at leat one trust anchor.  
> so the local machine need a lot of computing resources to finish the  
> resolving process.

Define 'a lot' in today's terms.  I'd argue that the days of CPU/ 
memory/bandwidth constrained end user devices are long past.

> if  it usually locates in recursiver name server or some special  
> host, the local host just send a query to that machine. if so, the  
> data transfered between the local lost and the resolver is not  
> secured, we need another mechanism to secure the data transfer.

Yep.  See TSIG (or IPSEC if you prefer).

Regards,
-drc

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 5 May 2009 16:46:56 +0200

On Tue, May 05, 2009 at 10:01:42AM +0800,
 YAO Jiankang <[email-masked]> wrote 
 a message of 16 lines which said:

>  resolver? 

You mean stub resolver? Because, on the vast majority of machines, the
normal resolver is certainly not "in the local host".

> or it usually locates in recursiver name server or some special
> host?

Both are possible and reasonable and I do not think it would be wise
to mandate one specific approach.

> resolver, every machine must be configured at leat one trust
> anchor. so the local machine need a lot of computing resources to
> finish the resolving process.

Management of trust anchors is certainly a big issue, computing
resources are not for the typical PC, which has so many unused
processing power that it must run 3D screensavers to use at least a
part of it.

> secured, we need another mechanism to secure the data transfer.

The client and the recursive resolver are often in the same network
(for some definition of network, I did not say "in the same LAN") so
the security issues are less pressing than in the global Internet.

---

From: "YAO Jiankang" <[email-masked]>
Date: Wed, 6 May 2009 11:11:35 +0800

----- Original Message ----- 
From: "Stephane Bortzmeyer" <[email-masked]>
To: "YAO Jiankang" <[email-masked]>
Cc: "IETF DNSOP WG" <[email-masked]>
Sent: Tuesday, May 05, 2009 10:46 PM
Subject: Re: [DNSOP] where is the validating resolver ? Re: WGLC: DNSSECTrust Anchor Configuration and Maintenance

> processing power that it must run 3D screensavers to use at least a

thanks for your information.
so we can say that in the current practise, the (validating ) resolvers are not run by local host or machine.

> (for some definition of network, I did not say "in the same LAN") 

so if we can say  if dnssec is not supported by tsig or ipsec, it is still not safe since the client and the recursive resolver are not secured ?

>so

maybe it is less pressing, 
but if the security problems occure "in the same LAN", it will be more serious  for the local users than the problem in the global internet, and impact all the users  "in the same LAN".

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Tue, 5 May 2009 23:11:44 -0500

On May 5, 2009, at 10:11 PM, YAO Jiankang wrote:
> so we can say that in the current practise, the (validating )  
> resolvers are not run by local host or machine.

I don't think we can say a lot about current practice, and we  
definitely can't say this.   There is at least one open-source DNSSEC  
validating stub resolver, and I would argue that it's the right  
solution.   I don't know what percentage of DNSSEC nodes are secured  
using a validating stub resolver, nor how many are secured using a  
validating cache.    The state of the art right now is that the root  
zone isn't signed, and most TLDs aren't signed.   So I think mostly  
people simply are not using DNSSEC in day-to-day practice yet.   So we  
shouldn't take what is being done now as a guide for what should be  
done.

> so if we can say  if dnssec is not supported by tsig or ipsec, it is  
> still not safe since the client and the recursive resolver are not  
> secured ?

A validating cache does provide security against cache poisoning  
attacks, which is an important attack vector.   However, if you have  
not cryptographically secured the connection between the stub resolver  
and the validating cache, your only protection against in-path attacks  
is whatever controls you have in place to isolate end nodes from each  
other and keep routers from being hacked.   So I would say that you  
don't have a complete security solution if you do not have a secured  
link between the client and the validating cache.   But you do gain  
some benefit from having a validating cache, even if the link to your  
stub resolver is not cryptographically secure.

> but if the security problems occure "in the same LAN", it will be  
> more serious  for the local users than the problem in the global  
> internet, and impact all the users  "in the same LAN".

Yup.   This is why I'm inclined to argue that best practice is to  
validate on the end node.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 May 2009 11:32:26 -0400

> so we can say that in the current practise, the (validating ) resolvers are not run by local host or machine.

I don't think you can say that.  What you can say is that in current
practice, DNSSEC is hardly deployed at all.

Microsoft's current plan is to deploy the validator in the recursive
resolvers first, relying on IPSec between the end nodes and the
recursive resolver to secure that last hop.  For many environments,
that's a perfectly good answer (but it surely won't be the right
answer to every case).
 
> so if we can say  if dnssec is not supported by tsig or ipsec, it is still not safe since the client and the recursive resolver are not secured ?

Or SIG(0), or by pushing validation out to the end node.

Note that each end node is in a position to do this for itself.  If a
request arrives at a recursive, validating resolver with the CD bit
set, then that recursive resolver MUST return whatever security data
it gets to the originating queryier.  It also MAY do validation
itself according to local policy, but it's not allowed to return
SERVFAIL if the validation fails: it's just supposed to hand back the
apparently-bogus answer anyway.  This allows for the case where the
end node has a trust anchor that will allow the response to validate,
even though the intermediate system (i.e. recursing resolver) doesn't.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 May 2009 07:28:45 +1000

> even though the intermediate system (i.e. recursing resolver) doesn't.

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 May 2009 23:52:47 +0200

In your previous mail you wrote:

   > resolvers are not run by local host or machine.
   
=> between the two solutions, not-validating security-aware resolver
and validating security-aware resolver, it is clear the first is
far easier: it needs only to check the AD bit and to use a protected
channel to get responses from a validating cache server. It is enough
if handling of no validation (i.e., responses without the AD bit) is
not critical, for instance in OpenSSH which includes exactly this.
 But if no validation or validation error cases are critical this is
impossible to debug: the information which hopefully can help to
understand an unexpected result is kept on the caching server. So
IMHO it is an easy solution until it becomes not so easy or not easy
at all...

Regards

[email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 12 May 2009 13:48:18 -0400

At 22:30 29/04/2009, Paul Hoffman wrote:
>At 8:13 PM +0200 4/22/09, Peter Koch wrote:
> >Please review the draft and send comments and/or statements of support or
> >non-support to the WG mailing list.
> >There will be a five reviewer threshold.
>
>I support the publication of this document. Some comments:
>
>Section 2: "Using a DS format is also recommended because it is 
>smaller than the DNSKEY format and is easier to enter manually, 
>either by typing or cutting and pasting." I don't know of anyone who 
>can accurately type Base64 for more than a few bits worth. I agree 
>that cut-and-paste of Base64 for DS is easier than for a DNSKEY.

DS has base16 format which is easier than Base64 for typing and visual
inspection.

>Section 3: "Priming can occur when the validating resolver starts, 
>but a validating resolver SHOULD defer priming of individual trust 
>anchors until each is first needed for verification." I disagree 
>with this as a SHOULD; "may want to" is much more appropriate. I see 
>nothing wrong with wanting to get the first round of crypto out of 
>the way at startup.

Good point,
How about s/SHOULD/MAY want to/ ?

>Section 3: "Following are the steps a validating resolver SHOULD 
>take to prime a configured trust anchor:". What do you propose they 
>do if they don't follow the SHOULD? All four of those steps feel 
>pretty damn required.

I have no problem upgrading them all to MUST but we got pushback on that
in earlier version:

>Section 4, "Trusted update mechanism": "This mechanism is 
>realistically only feasible for updating a small number of trust 
>anchors, such as for the top-level domains." That statement is 
>conjecture unsupported by facts. What is so hard about doing this 
>for a few thousand trust anchors? The queries will be spread over 
>hours (if not weeks). Maybe remove the sentence, or soften it.

If vendor X is willing to become a TAR for large number of domains that is
fine, I think we assumed (possibly incorrectly) that vendors were not in the
TAR business.
For example how quickly will Apple be able to push out a new set of TA's
to the millions of clients they have?

         thanks for the comments
         Olafur

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 May 2009 11:10:40 -0700

At 1:48 PM -0400 5/12/09, Olafur Gudmundsson wrote:
>>Section 2: "Using a DS format is also recommended because it is smaller than the DNSKEY format and is easier to enter manually, either by typing or cutting and pasting." I don't know of anyone who can accurately type Base64 for more than a few bits worth. I agree that cut-and-paste of Base64 for DS is easier than for a DNSKEY.
>

The sentence in the doc is specifically about typing. Typing hex may be easier than typing Base64, but it is also more tedious and probably about as error-prone.

>>Section 3: "Priming can occur when the validating resolver starts, but a validating resolver SHOULD defer priming of individual trust anchors until each is first needed for verification." I disagree with this as a SHOULD; "may want to" is much more appropriate. I see nothing wrong with wanting to get the first round of crypto out of the way at startup.
>
>Good point,

No, s/SHOULD/may want to/. There is no interoperability or security reason for using 2119-style language here.

>>Section 3: "Following are the steps a validating resolver SHOULD take to prime a configured trust anchor:". What do you propose they do if they don't follow the SHOULD? All four of those steps feel pretty damn required.
>

Understood. However, if you have this as SHOULD, you need to explain when the reader is allowed to not do one or more of the steps. Leaving it to the reader's imagination is a sure-fire way to have them choose incorrectly.

>>Section 4, "Trusted update mechanism": "This mechanism is realistically only feasible for updating a small number of trust anchors, such as for the top-level domains." That statement is conjecture unsupported by facts. What is so hard about doing this for a few thousand trust anchors? The queries will be spread over hours (if not weeks). Maybe remove the sentence, or soften it.
>

>From the traffic I have seen on the various DNSSEC lists, that is definitely an incorrect assumption. In fact, some people have pushed the notion that distribution of DNSSEC trust anchors by the software vendors is likely to be more stable than other choices. As much as I hate to admit it, that rings true to me.

>to the millions of clients they have?

Apple can decide that for themselves. They already push out much larger software updates, as do most software vendors. Even a "large" TAR is probably smaller than many software updates that we all live with today.

--Paul Hoffman, Director
--VPN Consortium

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 12 May 2009 14:08:23 -0400

At 14:45 22/04/2009, Edward Lewis wrote:
>At 20:13 +0200 4/22/09, Peter Koch wrote:
> >this is to initiate a working group last call on
> >
> >        "DNSSEC Trust Anchor Configuration and Maintenance"
> >       draft-ietf-dnsop-dnssec-trust-anchor-03.txt
> >
> >ending Friday, 2009-05-08, 23:59 UTC.  The tools site gives easy access to
> >diffs and such under
> > <http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-trust-anchor-03>.
>
>
>I keep forgetting this bit of document jockeying - can an Informational use
>RFC 2119 terms in a normative way?
>
>...
>#3.  Trust Anchor Priming
>    ...
>#  3.  Verify that the DNSKEY RR corresponding to the configured trust
>#      anchor (i.e., the DNSKEY whose hash is configured) appears in the
>#      DNSKEY RRSet and that this DNSKEY RR has the Zone Key Flag
>#     (DNSKEY RDATA bit 7) set.  (This bit only indicates that the
>#      DNSKEY is allowed to sign the zone.  This DNSKEY may or not be a
>#      zone signing key.)
>
>Last sentence? - "This DNSKEY might not be a zone a zone signing key.")
>
>But I'm not sure what is meant.  At first the paragraph reads - make 
>sure the Zone Key Flag is set and later says it "may or [may] not be 
>a zone signing key."
>
>Do you mean that "this" key could be a "key signing key?"

We are trying to say that the key can be both KSK and ZSK but does not
have to be.

How about: "this DNSKEY might also be a zone signing key"?

>#  4.  Verify that the DNSKEY RRSet is signed by one of the DNSKEYs
>#      found in the previous step, i.e., that there exists a valid RRSIG
>#      (cryptographically and temporally) for the DNSKEY RRSet generated
>#      with the private key corresponding to the DNSKEY found in the
>#      previous step.
>
>And here, are you saying that "this DNSKEY RR"'s private companion 
>has to sign the key set for all this to work?  In step three you 
>refer to a singular ("this") key, in step four it is plural ("is 
>signed by one of the").

you are right step 3 should be plural as well.

>...
>#  For this reason, old trust anchors SHOULD be removed from a
>#  validating resolver's trust anchor list soon after the corresponding
>#  keys are no longer used by the zone, as described in RFC 5011
>#  [RFC5011].
>
>Recommend that the priming be done often enough to capture revoked
>DNSKEY RR's - so that the zone doens't have to keep them indefinitely.

Well RFC5011 requires you scan at least once a month, and recommends higher
frequency, is that sufficient?

># 4.  Trust Anchor Maintenance
>#
>#   Trust anchors correspond to zones' key signing keys and these keys do
>
>  <keeping the terminology clean>
>
>Trust anchors *could* be zone signing keys.  Still I think you want 
>this here - SEPs?  Is that what is meant?

Same as above KSK and ZSK can be one key. There is no requirement that
a KSK have the SEP bit set only a recommendation.

>(RFC 4034:
>2.1.1.  The Flags Field
>...
>    Bit 15 of the Flags field is the Secure Entry Point flag, described
>    in [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a
>    key intended for use as a secure entry point.  This flag is only
>)
>
># 5.  Security considerations
>#
>#   This document proposes a standard format for documenting DNSSEC trust
>#   anchors.
>
>I didn't see a standard format (a la a zone file).  Just "use the DS 
>fields."  Perhaps I was expecting examples and such.

We assumed (possibly incorrectly) that having a reference was sufficient.

         thanks for your comments

         Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 12 May 2009 14:18:05 -0400

At 15:05 22/04/2009, Paul Wouters wrote:
>On Wed, 22 Apr 2009, Peter Koch wrote:
>
>It seems a comma is missing between Scott's name and mine.

Fixed,

>One issue came up recently with the dnssec-conf package related
>to Section 4, Trusted update mechanism..
>
>If an OS ships with preloaded trust anchors, and the medium is
>used over a year after it was created, eg an old CD/DVD copy, it
>might cause DNS to complete fail due to loading rolled over
>trust anchors. This DNS failure will prevent it from obtaining
>an updated trust anchor update if those reside within one of these
>zones.
>
>The question is what to do, or what to recommend. For Fedora/EPEL,
>I'm leaning towards automatically disabling all trust anchors (which
>includes DLV) if the package build date is older then 9 months. At
>the same time, we will commit to releasing at least a new package
>every 6 months, even if no changes were made and we are just bumping
>the release number. Upon package update, the resolver is restarted
>and the same check that disabled the trust anchors before will now
>accept the new package date, and enable trust anchors again.
>
>It might make sense to add a warning about this issue in the RFC?

IMHO the OS update package mechanism should be a signed update that
lives longer than any DNS TA distribution file.
I see two different issues here:
         a Software Update with TA's should only be valid for a certain
                 time window
         ability of a system that is loaded/restarted long time after
                 it is "configured" to perform DNSSEC verifications.

On the first one: send text
On the second one: we need a different mechanism see Wouter's draft
on trust history.
If we had Trust history and a history interpreter then the age of
the distribution would not matter that much.

         Not sure what to do here
         Olafur

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 May 2009 16:28:01 -0400 (EDT)

On Tue, 12 May 2009, Olafur Gudmundsson wrote:

>> Section 3: "Priming can occur when the validating resolver starts, but a 
>> validating resolver SHOULD defer priming of individual trust anchors until 
>> each is first needed for verification." I disagree with this as a SHOULD; 
>> "may want to" is much more appropriate. I see nothing wrong with wanting to 
>> get the first round of crypto out of the way at startup.
>
> Good point,

I think that would be "COULD" then....

> fine, I think we assumed (possibly incorrectly) that vendors were not in the

It's a choice of "becoming a TAR vendor" or "outsource to ISC DLV". I still
believe the DLV should be used for signed entries in unsigned parents only,
and no i don't count the root, as to minimize the dependancy on one DLV
Registry.

> to the millions of clients they have?

I don't think commercial OS vendors have much of a problem here. The opensource
vendors, where updates are not a mantatory part of life, might have a harder
time.

Paul

---

From: [email-masked]
Date: Tue, 12 May 2009 22:18:35 +0000

On Tue, May 12, 2009 at 04:28:01PM -0400, Paul Wouters wrote:
> >>validating resolver SHOULD defer priming of individual trust anchors 
> >>until each is first needed for verification." I disagree with this as a 
> >>SHOULD; "may want to" is much more appropriate. I see nothing wrong with 
> >>wanting to get the first round of crypto out of the way at startup.
> >
> >Good point,

	i think i am going to weigh in on th eother side of the coin here.
	I'd posit s/SHOULD/SHOULD NOT/ ... Is there any good reason why 
	validation and resolution need to be in lock-step?

--bill

---

From: Edward Lewis <[email-masked]>
Date: Tue, 12 May 2009 18:55:43 -0400

>We are trying to say that the key can be both KSK and ZSK but does not

Oh...

>How about: "this DNSKEY might also be a zone signing key"?

Yeah.

>frequency, is that sufficient?

Sure.

...
>a KSK have the SEP bit set only a recommendation.

But then you should be referring to SEP and not KSK for the most 
part.  I think.

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

Getting everything you want is easy if you don't want much.