Subject: [DNSOP] Should draft-ietf-dnsop-rfc4641bis cover RFC 5011 practices?

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Mar 2009 08:34:32 -0700

It feels like a lot of DNSSEC questions these days are being answered by "that's covered if you use RFC 5011". If so, then maybe proper use of RFC 5011 (such as when to assume that a zone is *really* being signed, not just for practice) should be part of draft-ietf-dnsop-rfc4641bis.

--Paul Hoffman, Director
--VPN Consortium

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 19 Mar 2009 09:41:34 +0100

On 16 mrt 2009, at 16:34, Paul Hoffman wrote:

> It feels like a lot of DNSSEC questions these days are being  
> answered by "that's covered if you use RFC 5011". If so, then maybe  
> proper use of RFC 5011 (such as when to assume that a zone is  
> *really* being signed, not just for practice) should be part of  
> draft-ietf-dnsop-rfc4641bis.

I think you have a point. I can imagine that such section would be  
about putting trust in a trust-anchor and the considerations that  
apply there. Shooting from the hip here are some considerations:

- When to trust a trust anchor:
   * whenever the zone-owner declares that a key is ready to be used  
as trust-anchor and
   * whenever you, as validator administrator, are satisfied that the  
rollover procedure
     is documented clearly enough and you are confident you can track  
the rollovers

- When not to trust a trust anchor:
   * when a key appears in a zone and there is no trusted out-of-band  
communication that
     such key is in production.

- Cases where transitive trust may work:
   * when a trusted third party validates the key-zone binding, the  
production
     readiness, and tracks the keys. (ITAR)
   * when copying zone data from a parental zone to which you have a  
DNS trust relation.
     I can see rare cases why you would want to establish a trust- 
anchor in the middle of
     a chain of trust that is in place. But if you follow this route  
I'm not sure about if
     there is a fate sharing argument that renders this sort of  
configuration useless.

Obvious missing points?

I've added this as open issue: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration

--Olaf

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 19 Mar 2009 18:48:50 +0100

Also, RFC 5011 may adapt key rollover practices.
In short this means that when a key may be removed because it is
considered dead, it should stay in the zone for one RRSIG TTL more with
its REVOKED bit set before removing it from the zone. This way, rfc5011
enabled resolvers can update their trust anchors in-band.

Matthijs

Olaf Kolkman schreef:
>> It feels like a lot of DNSSEC questions these days are being answered
>> by "that's covered if you use RFC 5011". If so, then maybe proper use
>> of RFC 5011 (such as when to assume that a zone is *really* being
>> signed, not just for practice) should be part of
> I think you have a point. I can imagine that such section would be about
> putting trust in a trust-anchor and the considerations that apply there.
> Shooting from the hip here are some considerations:
> 
>   * whenever the zone-owner declares that a key is ready to be used as
> trust-anchor and
>     is documented clearly enough and you are confident you can track the
> rollovers
> 
>   * when copying zone data from a parental zone to which you have a DNS
> trust relation.
>     I can see rare cases why you would want to establish a trust-anchor
> in the middle of
>     a chain of trust that is in place. But if you follow this route I'm
> not sure about if
> I've added this as open issue:
> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration
> 
> 
> --Olaf
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: TSG <[email-masked]>
Date: Thu, 19 Mar 2009 11:54:59 -0700

Matthijs Mekking wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
This is more about use policy than anything else.

By the way since I personally coined the term "Trust Anchor" in PKIX 
towards the late-1990's and got hammered by Dr. Kent for it, maybe I 
should get to tell you what it means... Trust anchors by pure definition 
are reliable points of reference which intended to make the content they 
anchor portable, that is to say comparable in a like manner to other 
like-anchored content. That said, a timestamp of any number of types can 
be a trust-anchor as can a token created through some form of 
cryptographic process.

Scary thought that eh?

Todd Glassey
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQEVAwUBScKFgg8yVCPsQCW5AQJnCQf/QLbLjp85Zp7zQPvb9z8KGdeCz1O52rGz
> boMljfuOcnvk9iZy/pZNnbyUT0msMX64FryiS4CGXNTZ/Qeen8+87KqTSI85/Wpo
> 2r/vebDrZU2MUNIbgYc/4Jxi0vtutsBrpT3Vvop8TpxL5DcfuMs8O1edbDcC/dw5
> AFkzb1a1SF3GRxjnJTWzv3KsYHABGCfyT9d25bRc02iJgXjZqwxrpI2fDPG+Dog0
> PnQ1Mc15vbQYO1g7PFBHv08qyAfuqfuUXGqy7aUB+c+SCZcveHRe4/wEVMw6mGtv
> UCJHzNldYcDJrhwyN9HLbsVKxTDf+W1Y/5TSNk9iCVELvMtOpziELg==
> =E+dk
> -----END PGP SIGNATURE-----

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Mar 2009 14:28:57 -0700

As much as I hate to engage in threads like this, I would like to make a factual correction.

At 11:54 AM -0700 3/19/09, TSG wrote:
>By the way since I personally coined the term "Trust Anchor" in PKIX towards the late-1990's

This is provably false. Carlisle Adams was the first to use the term on the PKIX mailing list in January of 1998.

--Paul Hoffman, Director
--VPN Consortium

---

From: Todd Glassey CISM CIFI <[email-masked]>
Date: Thu, 19 Mar 2009 16:21:37 -0700

> This is provably false. 

I am glad you said that in print Paul - you are wrong.  I coined the 
term... PERIOD.
> Carlisle Adams was the first to use the term on the PKIX mailing list in January of 1998.
>
> --Paul Hoffman, Director
> --VPN Consortium
>   
Yeah - no.... actually somewhere between 16 and 24 months earlier Steve 
read me the riot act for "coining new marketing terms inside PKIX"  he 
threatened to remove me if I didnt stop too as I recall and that was its 
first public use in the PKI community. What was really freaking cool was 
how stupid Carlilise's use of my terminology made Kent look.

There are actually three terms - and they come from a work I did on 
business process work-flows in 1993.

Trust Anchor - An aspect of a trust process used to correlate the 
content of the process to some other reference  data-point. This could 
include any data-points or controls which provide positive reporting as 
to authentications, non-repudiation and synchronization

Portable Trust - Trust Models which can be represented as discrete 
policy models. The key source of portability in content records would be 
timestamps by the way.

Verifiable Relation - The item that the Trust Anchor provides the 
anchoring of.

 From an Audit perspective Trust Anchors are used to create reliable 
reporting models which are used to implement the social requirements for 
human processes in a digital context. That's a bunch of hand waving for 
systems and controls which implement human processes as they would be in 
the real world, but in a cyber-context. Content which is anchored is 
made portable, that is comparable to any other content processed through 
a child or like process.

Sorry...

Todd Glassey