Re: From whence we came...

["James Seng/Personal" <jseng@pobox.org.sg>]

There is a differences between what you and me talking:

You believe that DNS should distribute raw keys and only raw-keys. "we
have no interest in certificates. We just want keys. Others may want
certificates, but that is their business."

I believe keys distribution cannot be discussed separately with certs.
Rawkeys can be distribute as it-is or can be distributed signed in cert.
There is no such thing as "us" or "their" problem here. Both are
problems within the IETF, altho from areas, both needs to be resolved
eventually, one way or the other, now or later.

If the requirements is only how to distributed raw-key over DNS (and
therefore, implicitly decided to trust the DNSSEC hierarchy for all
keys), then your mail is probably the right follow up to that line of
discussion.

If the requirements is one that we hope to keys, either in raw-keys or
in certs, then my mail is probably the right follow up to this line of
discussion.

So lets choose: which one is our requirement?

-James Seng

----- Original Message -----
From: "Michael Richardson" <mcr@sandelman.ottawa.on.ca>
To: <keydist@cafax.se>
Sent: Sunday, January 06, 2002 5:48 AM
Subject: Re: From whence we came...


> -----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-----