[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Key Management, anyone? (DNS keying)
Ran Atkinson said:
> The IETF requires that _implementations_ of IP also _implement_
> support for DNS. The IETF does NOT require that users actually _USE_
> DNS. Now most users DO use DNS because it is widely implemented and
> it is often easier to use than typing an IP number. However, on
> occasion users (e.g. me) don't use DNS and instead just type an IP
> number on the command line (e.g. "telnet 1.2.3.4") and this isn't
> violating any IETF requirement.
I agree it's desirable to maintain the ability to use manual keying,
like the ability to use manual IP addressing.
> Similarly, the IPsec WG would be wrong to try to mandate that "users
> MUST use DNS to obtain IPsec keys", while it might be very legitimate
> for the IPsec WG to mandate that "IPsec implementations SHOULD/MUST
> also implement support for DNSsec" if that is what the IPsec WG were
> to decide to do. [1]
In the context of "If you use the IPSEC WG's key management protocol",
it would be a perfectly fine statement for us to say "the key
management software MUST use DNS to obtain IPsec keys". It's like the
SMTP spec saying that mailers MUST look for DNS MX records rather than
simply looking up domain names in a "host table" file somewhere. If
we build a mechanism to solve a problem, and expect to use it widely,
then we should mandate its use in that problem domain, to guarantee
interoperability.
The effort we're going through to define a single key management
protocol would be wasted, if that unified key management protocol
ended up having to try six different ways to find the other guy's
public key. Or to find out if the other guy supports IPSEC at all.
Those folks who use somebody else's key management protocol, of course,
can get keys by telepathy, voodoo, or by extracting them from a key
escrow database. The WG should never say "this is the only key
management protocol or key publication protocol you can use". Instead
it's "if you want to interoperate with all the other hosts that use
this standard, then you should use the protocols we specify".
Communications networks that have different needs are completely free
to implement both WG-keying to talk to the public and e.g. MIL-keying
to talk to each other.
The military will be using different packet-level transforms as well,
since Skipjack is not as far as I know on the IETF standards track.
That would be troublesome, since there is no published spec. I don't
think NSA can twist IESG's arm the way they twisted NIST's, to issue a
standard which says "Poof, it's a standard, even though we refuse to
tell you how it works". They might even have trouble getting IANA to
issue them an algorithm number without specifying the algorithm that
it identifies.
Given that the key-escrowed government network will not use either
IPSEC standard transforms, or an IPSEC standard key exchange protocol
like Oakley or Photuris, it clearly need not use DNS keys either. But
by the same token, their needs or desires are no reason for the rest
of us to *avoid* using DNS keys.
> NOTE 1: IETF rules prohibit a standards-track RFC at level N in the standards
> process from back referencing a standards-track RFC at a level less
> than N. At present, IPsec is a Proposed Standard and DNSsec is not
> a standards-track RFC. This winter, IPsec will probably move to
> Draft Standard, but DNSsec is required to remain at Proposed Standard
> until (1) at least 6 months have passed since publication as a
> Proposed Standard RFC and (2) interoperability of multiple independent
> implementations is demonstrated. Hence, if the IPsec RFCs mandate
> implementation of DNSsec, then the progress of the IPsec RFCs is
> likely to be delayed accordingly. It is up to the WG as a whole
> to develop consensus on whether such an explicit standards-dependence
> is desirable.
Ran, please don't try to mislead the group on procedural issues.
The only IPSEC RFC that would require the use of DNSSEC (if any did)
is the IPSEC key management RFC. It isn't yet an Internet-Draft, let
alone a standards-track RFC; it's still being hashed out in a
smoke-filled room upon Jeff Schiller's request. DNSSEC will be way
ahead of it in the standards track, so there is no delay issue.
John Gilmore