IPSECKEY BOF at IETF-55 Atlanta 19 November 2002 Reported by Samuel Weiler Mailing list: ipseckey@sandelman.ottawa.on.ca To subscribe, put "subscribe ipseckey" in the body of a message to majordomo@sandleman.ottawa.on.ca Draft: draft-richardson-ipsec-rr-00.txt This is an effort to specify an RR to be used to distribute public keys and gateway addresses for opportunistic IPSEC, to replace the current use of both a TXT RR and a KEY RR. In years past, the DNS working groups were seen as being stingy with new RR type codes, so KEY was subtyped and used for both DNSSEC keys and application keys. A recent draft prohibits applications from using KEY. This is primarily an effort to replace the existing functionality, which requires a remote system's public RSA key and a IP address of it's gateway, both indexed by IP address. Scott Rose presented a synopsis of draft-ietf-dnsext-restrict-key-for-dnssec-04.txt, which prohibits applications from using the KEY RR to avoid large keysets at a zone apex, to avoid subtyping, and to separate administration of DNSSEC and application keys. He emphasized that the DNSSEC spec rewrite currently in progress does not forbid the use of DNS for storing application key material. There was some discussion of whether the problems the restrict-key draft purports to address are real. Subtyping is architecturally flawed -- DNS lookups are based on class/name/type, and there seemed to be widespread support for the idea that subtyping should be avoided. There was not consensus as to whether overflow to TCP, which is almost certain when you have application KEY RRs sharing a zone apex with DNSSEC KEYs, is _really_ problematic: application use of KEYs was not experimented with at previous workshops. Hugh Daniel expressed substantial frustration that the restrict-key draft seems to be going through before a replacement for use of the KEY RR is in place, especially given that there's deployed code using KEY for IPSEC. Steve Bellovin expressed great reluctance to hold up the DNSSEC spec to wait for this and pointed out that there isn't a protocol police -- no one is going to forcibly stop the use of KEY for IPSEC. There was much discussion of whether to focus on IPSEC keys or something more general. A more general BOF (SIKED) was held Minneapolis (March 2002), and the feedback from there was not to try to do everything at once and instead go for one protocol at a time. Furthermore, the trust model of each application (ie. S/MIME) may not match that of DNSSEC -- there are decisions that will have to be made per application. And the same logic that applied for evicting IPSEC from using KEY applies to reuse of an APPKEY RR type by multiple applications that will presumably need different additional/support data: subtyping is evil. Micheal presented an initial proposal for an IPSECKEY RR. It contains an extensible series of type-length-value tuples. Specific fields types would be: priority, v4/v6 addresses of gateway, FQDN of gateway, RSA key of gateway. There was some discussion of whether a hostname to key mapping (in the forward tree) would be more appropriate. The BOF chairs intend this effort to replace the existing functionality, which uses the reverse tree, and in order to have the naming model of this mapping match the IPSEC naming model, it's appropriate to use the reverse tree. A gateway needs to be specified because you may have boxes sitting behind an IPSEC gateway that need to delegate authority to make the IPSEC connections. The desired case is that nodes are their own gateways, in which case they list themselves or nothing as gateway. What if DNSSEC weren't available? You'd still be protected from some passive attacks, which has value. It is very easy to poison DNS caches, and while an active attack, it's not as difficult as a man-in-the-middle. A sample charter was presented with a single deliverable draft to published as soon as the queue opens with a final version in Jan/Feb and submission to the IESG in March. There was a noticeable hum in favor of requesting a WG with an IPSEC-specific charter and a timeline of six months. There was no noticeable hum when the room was asked if the effort was worthless.