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.