Stay Ahead With Linux Security News

network securityFreeS/WANDNS Key-Restrict

FreeS/WAN: DNS Key-Restrict Draft Threatens Public Key Distribution

This week's lists.freeswan.org Email Summary reports that Michael Richardson debated the new DNS Key-Restrict draft with folks from the list This email address is being protected from spambots. You need JavaScript enabled to view it.. If that draft is widely implemented, FreeS/WAN will need to use a different DNS record type to distribute public keys. Interesting stuff.. . .. This week's lists.freeswan.org Email Summary reports that Michael Richardson debated the new DNS Key-Restrict draft with folks from the list This email address is being protected from spambots. You need JavaScript enabled to view it.. If that draft is widely implemented, FreeS/WAN will need to use a different DNS record type to distribute public keys. Interesting stuff. The DNS (Domain Name Service) Working Group of the IETF (International Engineering Task Force) has decided to restrict the use of KEY records to DNSsec keys, and has published its intent in a Key-Restrict draft. This draft is an attempt to solve the "sub-typing problem": once you have more than one type of KEY, for DNSsec and other purposes, how do you differentiate between these types? Since Opportunistic Encryption (OE) is designed to rely on the KEY record to distribute IPsec public keys, the Working Group's decision affects the Linux FreeS/WAN project. Michael Richardson, Linux FreeS/WAN programmer, opposes the measures outlined in the draft. He commented, "[a]ny proposal that removes functionality without offering an immediate alternative is a complete and total non-starter." Notably, the draft does not suggest an alternative to the KEY record for other interests (for example IPsec and SSH) who are using, or would like to use, the KEY RR to distribute other information essential to network communications. Scott Rose remarked on the proposed solution: Restricting KEY to DNSSEC only does solve the sub-typing problem - for DNSSEC. For everything else that wishes to use the DNS to store keys (IPSec and SSH are the only 2 that come to mind). APPKEY faced the same problem - it just pushed the subtyping problem off to all the other protocols and left DNSSEC as thelucky one. He proposed an analogous effort for other key types: If it is good to restrict KEY to DNSSEC, then having a separate RR type for any other public key is a good idea too. In keeping with this idea, Derek Atkins suggested Michael Richardson "write a draft that defines a new FSKEY record that defines how to store FreeS/WAN keys in DNS". Derek added: My recollection of reading the OE draft was that you needed additional information above and beyond what was provided by the KEY record. In particular, IIRC, you needed a pointer to the gateway and the network size to use. This would be the perfect opportunity to combine this all into a single record! According to Scott, the whole process might benefit from a longer view. He recommended: a BOF [in Atlanta] about using DNS to support other applications and set up a general framework/process for getting any type of network information in the DNS. Not just keys. Michael commented that the problem needed to be solved soon: For another month or so, I can change how Opportunistic Encryption works. It will be painful, but we can do it. If the change is not proposed now, then we will continue deploying with the status quo, which is well supported. He insisted that the solution ought to be created by the folks who would restrict the use of the KEY record that FreeS/WAN now uses. More detail on the whole debate may be found in the thread. The link for this article located at FreeS/WAN Project is no longer available. . This week's lists.freeswan.org Email Summary reports that Michael Richardson debated the new DNS Key. week's, lists, freeswan, email, summary, reports, michael, richardson, debated. . LinuxSecurity.com Team

Aug 07, 2002 • LinuxSecurity.com Team Cryptography