Subject: Re: another's view on zone enum & on-line signing

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Nov 2004 17:33:57 -0500

-----BEGIN PGP SIGNED MESSAGE-----

[catching up on old threads]

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:
    Edward> Let's assume that you have a zone with a mix of critical
    Edward> data and (for lack of a better word) vanity data.  Critical
    Edward> would be the address record of your mail server.  Vanity
    Edward> would be a CNAME to the entry you are using at a conference.

    Edward> E.g. --->
    Edward> smtp           AAAA        <ip addr>
    Edward> marco.polo     CNAME       host-ripe49-139.example.net.

  (...lots of discussions...)

    Edward> Ultimately we determined (!= "and that's the way it is")
    Edward> that without a way to express to resolver/verifiers a policy
    Edward> that includes "these records can only be signed with this
    Edward> kind of key" and "those with the weaker key" it is useless
    Edward> for the server to use more than one key (per algorithm at a
    Edward> time). 

  The above is simply accomplished.

  zone1:
       example.       SOA ...
                      DNSKEY      offlinekey
       $ORIGIN example.
       smtp           AAAA        <ip addr>
		      DNSSIG(offlinekey)
       marco.polo     CNAME       marco.polo.online.example.
		      DNSSIG(offlinekey)
       online         NS	  name.
		      DS	  on-line-key
		      DNSSIG(offlinekey)

  zone2		      
       online.example SOA ...
		      DNSKEY	on-line-key
       marco.polo     CNAME     host-ripe49-139.example.net.
		      DNSKEY    marco.polo.SIG(0).key  
		      DNSSIG(on-line-key)

  The only downsides are: 
     a) chain of CNAMEs
     b) dyndns client has to either know about subzone.
	maybe some kind of enhanced ACL would permit the master for
	zone1 to figure out to forward the update.
     c) it would be nice if marco.polo's SIG(0) key could be in the
	parent zone.
     d) lots of stupid (BROKEN) resolvers do not follow CNAMEs when
	they should.

  Upside is that zone1 is probably big, and rewriting it is a pain.
  zone2 is almost entirely dynamic data... if you get in trouble, empty
it out again ;-)

{... I keep thinking that I should spend the time to get a law degree,
 so that I can win all flame wars involving security policy, by default}

]       ON HUMILITY: to err is human. To moo, bovine.           |  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/>