[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[IPSECKEY] minutes from BOF




Date: Sat, 14 Dec 2002 09:34:51 -0500 (EST)
From: Sam Weiler <weiler@watson.org>

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.


-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.