Re: From whence we came...

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

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


>>>>> "James" == James Seng/Personal <jseng@pobox.org.sg> writes:
    James> My first thought is to have a flag in the KEY to specify whether
    James> the KEY is a raw-key or a cert. But it seem pretty redundant since
    James> the cert may contain the key. It is possible for the apps to
    James> extract the key from the cert and ignore that the cert is

  Unnecessary. There is a KEY type which can indicate the format.
  There are only 256 of them, which I'm told has worried some people. I'm not
worried about that problem. 

  The problem of having many keys at the apex of a zone is something that I
understand, but only really affects HTTPS uses in my opinion, and I do not
think they are likely to switch to keys in DNS anytime soon. 

  The problem of sub-typing I recognize - I can't ask for your IPsec KEY
record, I have to ask for all KEY records and sort them later. This has bad
effects on DNS UDP/TCP usage, I agree.
  One answer is to burn RR #s instead. I'm not sure that this is worth it
either. If I name all of the uses that I can HOPE for and imagine for the
next decade, I get:
	1) IPsec
	2) SSH
	3) SMTP+TLS ("STARTTLS")
	4) user key for OpenPGP		(2.6-RSA and OpenPGP-DSA)
	5) user key for S/MIME
	6) some VoIP/RTP/QoS application [key used for authentication for 
					 bandwidth usage. Privacy via IPsec]
        7) HTTPS (eventually maybe...)
	8) a pop-up/message protocol	[assuming IMPP!=SIP]
	9) some SNMP usage		[assuming SNMP security does not go IPsec]

  I'm really stetching here. I spent ten minutes, and I couldn't come up with 
a #10. 

  Multiply by 2 because someone will screw up their format and need to do it
again. 

  Multiple return set by 2 or 3 because of keyrollover and DNS propogation
delay. (If you change keys very often, you may get as many as three keys in
flight. You may have to put tomorrow's key in DNS today to get it to
propogate in time for your usage tomorrow).

  My position is that no new "APPKEY" has any utility. Time to deploy
"APPKEY" is the same as the time to deploy "SSHKEY" or "IPsecKEY" or
"VoIPKEY" format, and I think that we want to avoid subtyping. I'm told that
later bind v8 versions can cope with RRs they don't understand. DJBDNS has a
format for putting in RRs that it doesn't speak. (It doesn't do KEY actually)

  The problem of turning DNS servers into KDCs has been brought up. People
are afraid that one would therefore make DNS servers more interesting targets 
for attacks. DNS servers are not usually as logically and physically secure
as KDCs. [there is a tale about a KDC at some institution, probably MIT, that 
got physically lost. It was in a closet that was walled over, but the box
never crashed, so it never mattered. But it couldn't be found.]
  I don't buy this argument - once you have DNSSEC, you have the KDC
issues anyway. People argue that some of these host/user keys are for more
valuable to crack than name->IP mappings. So be it. But those keys have to be 
served from somewhere. I think that I know a lot more about securing a DNS
server than I do about LDAP servers sitting atop MS-Access databases. 

  Caching only servers are not at risk as the data is internally integral.

  Our immediate requirements for key storage are simple:
  1) we want it easy to deploy. That means already present in shipping
     software.

  2) we have no interest in certificates. We just want keys. Others may want
     certificates, but that is their business.

  3) we would like to avoid multiple round trips (i.e. TCP) for getting the
     keys. We expect to do a lookup per host that is involved in some
     communication per hour. 

     [So if you have 10 hosts which talk to 100 unique web servers each every hour,
     then we would do 1000 lookups/hour] 	   

  4) we would like it easy for end-users to be able to get their info into
     DNS servers' reverse maps - particularly users who have iptelco.net
     accounts. This means pushing DNSUPD/DHCP/PPP(/AAA) cooperation.
	
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBPDd0hIqHRg3pndX9AQF0ogP/b0g337o/zwpXYruW8jmB8yIPqmjd/ioo
tUKvHlEEDzQT6MI4f/KLtrzvCczemZPhghaaJSh1SGU2rih/6cWPyxM5g80WUi+C
Bu55S09J2YcstQ2OVfvM9vMOy9kvnMM+BpPkundV2ivgs1+iDN61e2jfJRHpJAUP
5HPC3xjwFKM=
=m8ks
-----END PGP SIGNATURE-----