Re: How is DNSSEC
Dave Howe wrote: James A. Donald wrote: From time to time I hear that DNSSEC is working fine, and on examining the matter I find it is "working fine" except that DNSSEC is "working fine" as a technology. However, it is worth remembering that it works based on digitally signing an entire zone - the state of the world being what it is, most people prohibit xfer so any other technology that would allow a zonewalk is not going to be deployed. as far as I can tell, this is a basic design flaw, so isn't going to be rectified anytime soon. RFC 5155 rectifies this design flaw. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How is DNSSEC
On Fri, 21 Mar 2008 08:52:07 +1000 "James A. Donald" <[EMAIL PROTECTED]> wrote: > From time to time I hear that DNSSEC is working fine, and on > examining the matter I find it is "working fine" except that > > Seems to me that if DNSSEC is actually working fine, I should be able > to provide an authoritative public key for any domain name I control, > and should be able to obtain such keys for other domain names, and > use such keys for any purpose, not just those purposes envisaged in > the DNSSEC specification. Can I? It is not apparent to me that I > can. > You might want to look at RFC 3445 and draft-iab-dns-choices-05.txt. As for DNSSEC keys -- DNSSEC is for securing the DNS. Once you've done that, you can put other records in the DNS, but there are some subtle points in DNS RR design that should be heeded. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [mm] How is DNSSEC
[EMAIL PROTECTED] wrote: On Sat, Mar 22, 2008 at 03:52:49PM +, Ben Laurie wrote: [EMAIL PROTECTED] wrote: On Sat, Mar 22, 2008 at 02:46:40PM +, Ben Laurie wrote: [EMAIL PROTECTED] wrote: Er... Allow me the option o fdisbeleiving your assertion. PTR records can and do point to mutiple names. Some narrow implementations have assumed that there will only be a single data element and this myth - that PTRs only point to a single name - is and has been spread widely. You can disbelieve my assertion if you wish, but I am only quoting the RFC. RFC 1035, to be precise: "Address nodes are used to hold pointers to primary host names in the normal domain space." (section 3.5. IN-ADDR.ARPA domain). So, the "myth" is in the scripture. ah... open to interpretation. what is a "primary" host name? RFC 1035 does not say, in the case of hosts, but the intent is quite clear from the text on gateways: "Gateways will often have two names in separate domains, only one of which can be primary." the intent for gateways... hosts w/ multiple IP's (VMware etc) are not gateways. comparing oranges w/ dragonfruits. If you insist on language lawyering, I can play. I'd say it is clear from: a) The lack of a repeated PTR record for a host IP in the example, b) The use of the word 'primary', c) The fact that the authors felt it necessary to explain what they saw as an exceptional case, i.e. that a gateway could have two names that in the case of hosts, the authors expected there to only be a single PTR record for reverse lookup. Of course, we have the power to change RFCs. But there's a process for that. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [mm] How is DNSSEC
[EMAIL PROTECTED] wrote: On Sat, Mar 22, 2008 at 02:46:40PM +, Ben Laurie wrote: [EMAIL PROTECTED] wrote: Er... Allow me the option o fdisbeleiving your assertion. PTR records can and do point to mutiple names. Some narrow implementations have assumed that there will only be a single data element and this myth - that PTRs only point to a single name - is and has been spread widely. You can disbelieve my assertion if you wish, but I am only quoting the RFC. RFC 1035, to be precise: "Address nodes are used to hold pointers to primary host names in the normal domain space." (section 3.5. IN-ADDR.ARPA domain). So, the "myth" is in the scripture. ah... open to interpretation. what is a "primary" host name? RFC 1035 does not say, in the case of hosts, but the intent is quite clear from the text on gateways: "Gateways will often have two names in separate domains, only one of which can be primary." -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [mm] How is DNSSEC
On Sat, Mar 22, 2008 at 02:46:40PM +, Ben Laurie wrote: > [EMAIL PROTECTED] wrote: > > Er... Allow me the option o fdisbeleiving your assertion. > > PTR records can and do point to mutiple names. Some narrow > > implementations have assumed that there will only be a single > > data element and this myth - that PTRs only point to a single > > name - is and has been spread widely. > > You can disbelieve my assertion if you wish, but I am only quoting the > RFC. RFC 1035, to be precise: > > "Address nodes are used to hold pointers to primary host names > in the normal domain space." > > (section 3.5. IN-ADDR.ARPA domain). So, the "myth" is in the scripture. ah... open to interpretation. what is a "primary" host name? --bill > > -- > http://www.apache-ssl.org/ben.html http://www.links.org/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [mm] How is DNSSEC
[EMAIL PROTECTED] wrote: Er... Allow me the option o fdisbeleiving your assertion. PTR records can and do point to mutiple names. Some narrow implementations have assumed that there will only be a single data element and this myth - that PTRs only point to a single name - is and has been spread widely. You can disbelieve my assertion if you wish, but I am only quoting the RFC. RFC 1035, to be precise: "Address nodes are used to hold pointers to primary host names in the normal domain space." (section 3.5. IN-ADDR.ARPA domain). So, the "myth" is in the scripture. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How is DNSSEC
On Sat, Mar 22, 2008 at 10:59:18AM +, Ben Laurie wrote: > [EMAIL PROTECTED] wrote: > >On Fri, Mar 21, 2008 at 08:52:07AM +1000, James A. Donald wrote: > >>From time to time I hear that DNSSEC is working fine, and on examining > >>the matter I find it is "working fine" except that > >> > >>Seems to me that if DNSSEC is actually working fine, I should be able to > >>provide an authoritative public key for any domain name I control, and > >>should be able to obtain such keys for other domain names, and use such > >>keys for any purpose, not just those purposes envisaged in the DNSSEC > >>specification. Can I? It is not apparent to me that I can. > > > > > > actually, the DNSSEC specification -used- to support > > keys for "any purpose", and in theory you could use > > DNSSEC keys in that manner. However a bit of careful > > thought suggests that there is potential disconnect btwn > > the zone owner/admin who creates/distributes the keys as > > a token of the integrity and authenticity of the data in > > the DNS, and the owner/admin of the node to which the DNS > > data points. > > So far, so good. This disconnect doesn't seem to have done the CA > industry any harm, though. The CA business -is- to serve as a "notary" They attest to the binding o fthe key to holder. To date, thats NOT what a zone admin does, he is attesting that its HIS key, that it is HIS record in HIS database. Just because he has sold the right to use to someone else, is still his database and his data. Unless of course Nominet (for example) is now going to allow client driven dynamic updates - where the clients are in complete control of their data. (thats closer to James, assertion that he owns/controls his domain name) > > > Remember that while you may control your forward > > name (and not many people actually run their own DNS servers) > > it is less likely that you run your address maps - and for > > the paranoid, you would want to ensure the forward and > > reverse zones are signed and at the intersection, there is > > a common data element which you can use. > > Non sequiteur, plus I can't see why paranoia would prompt me to want to > do this? What does it prove? The argument is, again, to James asserton that he owns his domain name. In point of fact, every node has at least two "names" in the DNS, the forward (which gets most of the attention) and the reverse - which is nearly always controled by your ISP. DNSSEC validation along one path in the DNS graph is reassuring (or so it is claimed). I posit that validation over two, generally non-overlapping administrative spheres of influence, in the DNS graph would give a higher level of assurance. Couple this with finding the identical x509 cert at the origin of the validation chain for both paths - and I think I have a much higher confidence that I am actually going to be sending packets to the "right" node. > Also, PTR records are only supposed to point to "primary domain names". > Since it is common for hosts to have many names resolving to the same IP > address, by definition most of these will not correspond to the reverse > lookup. Er... Allow me the option o fdisbeleiving your assertion. PTR records can and do point to mutiple names. Some narrow implementations have assumed that there will only be a single data element and this myth - that PTRs only point to a single name - is and has been spread widely. > > To do what you want, want, you might consider using the > > CERT-rr, using the DNS to distribute host-specific keys/certs. > > And to ensure that the data in the DNS was not tampered with, > > using DNSSEC signed zones with CERT-rr's would not be a bad > > thing. In fact, thats what we are testing . > > Who is "we" and what exactly are you testing? We is USMIR, the registry for .UM - www.nic.um --bill > > Cheers, > > Ben. > > -- > http://www.apache-ssl.org/ben.html http://www.links.org/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How is DNSSEC
[EMAIL PROTECTED] wrote: On Fri, Mar 21, 2008 at 08:52:07AM +1000, James A. Donald wrote: From time to time I hear that DNSSEC is working fine, and on examining the matter I find it is "working fine" except that Seems to me that if DNSSEC is actually working fine, I should be able to provide an authoritative public key for any domain name I control, and should be able to obtain such keys for other domain names, and use such keys for any purpose, not just those purposes envisaged in the DNSSEC specification. Can I? It is not apparent to me that I can. actually, the DNSSEC specification -used- to support keys for "any purpose", and in theory you could use DNSSEC keys in that manner. However a bit of careful thought suggests that there is potential disconnect btwn the zone owner/admin who creates/distributes the keys as a token of the integrity and authenticity of the data in the DNS, and the owner/admin of the node to which the DNS data points. So far, so good. This disconnect doesn't seem to have done the CA industry any harm, though. Remember that while you may control your forward name (and not many people actually run their own DNS servers) it is less likely that you run your address maps - and for the paranoid, you would want to ensure the forward and reverse zones are signed and at the intersection, there is a common data element which you can use. Non sequiteur, plus I can't see why paranoia would prompt me to want to do this? What does it prove? Also, PTR records are only supposed to point to "primary domain names". Since it is common for hosts to have many names resolving to the same IP address, by definition most of these will not correspond to the reverse lookup. To do what you want, want, you might consider using the CERT-rr, using the DNS to distribute host-specific keys/certs. And to ensure that the data in the DNS was not tampered with, using DNSSEC signed zones with CERT-rr's would not be a bad thing. In fact, thats what we are testing . Who is "we" and what exactly are you testing? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How is DNSSEC
James A. Donald wrote: From time to time I hear that DNSSEC is working fine, and on examining the matter I find it is "working fine" except that Seems to me that if DNSSEC is actually working fine, I should be able to provide an authoritative public key for any domain name I control, and should be able to obtain such keys for other domain names, and use such keys for any purpose, not just those purposes envisaged in the DNSSEC specification. Can I? It is not apparent to me that I can. There are two major issues with DNSSEC right now. Neither of them is that it isn't working. Firstly, the root is not signed. This means there's no easy way for the relying party to establish the correctness of the key on your domain. Secondly, although we have DNS servers and resolvers, software that uses DNS is largely unaware of DNSSEC and so has absolutely no idea what to do when one of the many possible cryptographic/proof failures occurs. Very little thought has gone into what should be done, even in software that is aware. That said, if you want to distribute keys with DNSSEC, then RFC 4398 standardises ways to do a number of them, and can be extended to cover more. RFC 4255 gives you SSH host keys, too. If you want to do something ad hoc, then there are always TXT records, though I guarantee this will make the DNS people hate you forever. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How is DNSSEC
* James A. Donald: > From time to time I hear that DNSSEC is working fine, and on examining > the matter I find it is "working fine" except that > > Seems to me that if DNSSEC is actually working fine, I should be able > to provide an authoritative public key for any domain name I control, > and should be able to obtain such keys for other domain names, and use > such keys for any purpose, not just those purposes envisaged in the > DNSSEC specification. Can I? It is not apparent to me that I can. DNS is hierarchical. Nobody wants the DoD (who are traditionally quite good at keeping secret data) or any other institution to keep keys at important positions in the hierarchy. And nobody wants to be the keep irreplaceable keys, either, which makes introduction at levels below the DNS root difficult. This is not a problem with the browser PKI because it's possible to replace root certificates with a software update (which can be automated in many cases). And as Bill pointed out, it's not possible to use the DNS keys directly. However, you can bootstrap another key based on data from DNS. This even works without DNSSEC. DKIM does that, for instance. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How is DNSSEC
James A. Donald wrote: From time to time I hear that DNSSEC is working fine, and on examining the matter I find it is "working fine" except that DNSSEC is "working fine" as a technology. However, it is worth remembering that it works based on digitally signing an entire zone - the state of the world being what it is, most people prohibit xfer so any other technology that would allow a zonewalk is not going to be deployed. as far as I can tell, this is a basic design flaw, so isn't going to be rectified anytime soon. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How is DNSSEC
On Fri, Mar 21, 2008 at 08:52:07AM +1000, James A. Donald wrote: > From time to time I hear that DNSSEC is working fine, and on examining > the matter I find it is "working fine" except that > > Seems to me that if DNSSEC is actually working fine, I should be able to > provide an authoritative public key for any domain name I control, and > should be able to obtain such keys for other domain names, and use such > keys for any purpose, not just those purposes envisaged in the DNSSEC > specification. Can I? It is not apparent to me that I can. actually, the DNSSEC specification -used- to support keys for "any purpose", and in theory you could use DNSSEC keys in that manner. However a bit of careful thought suggests that there is potential disconnect btwn the zone owner/admin who creates/distributes the keys as a token of the integrity and authenticity of the data in the DNS, and the owner/admin of the node to which the DNS data points. Remember that while you may control your forward name (and not many people actually run their own DNS servers) it is less likely that you run your address maps - and for the paranoid, you would want to ensure the forward and reverse zones are signed and at the intersection, there is a common data element which you can use. To do what you want, want, you might consider using the CERT-rr, using the DNS to distribute host-specific keys/certs. And to ensure that the data in the DNS was not tampered with, using DNSSEC signed zones with CERT-rr's would not be a bad thing. In fact, thats what we are testing . > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
How is DNSSEC
From time to time I hear that DNSSEC is working fine, and on examining the matter I find it is "working fine" except that Seems to me that if DNSSEC is actually working fine, I should be able to provide an authoritative public key for any domain name I control, and should be able to obtain such keys for other domain names, and use such keys for any purpose, not just those purposes envisaged in the DNSSEC specification. Can I? It is not apparent to me that I can. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
