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

Re: Key Management, anyone?




>We require the use of DNS to run IP (see RFC 1123, Host Requirements,
>section 6.1).  Why should we not require the use of DNS to run IPSEC?

Hmm.  Perhaps permit me to narrow those statements a bit to try to clarify
something (mandating implementation support vs. mandating use) that
periodically causes confusion within the IPsec WG.

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.

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]

It is NOT the usual IETF practice to impose mandates on users.  It is
often the IETF practice to impose implementation mandates on implementers.

>> *Hardened DNS (DNS-certified keys for the purpose of improving
>> the reliability of name-to-address mapping) is quite useful for it's
>> own sake. It's just seductively misleading to extend the use of
>> "DNS keys created to secure DNS data" into the domain of "keys to
>> secure IPSEC traffic".
>
>If you know of a security problem with using the DNS protocols and/or
>the RSA/MD5 algorithms to distribute public keys which could be used to
>secure IPSEC traffic, then I propose that you announce it.  Your last
>two messages have cast aspersions, without making specific what your
>perceived problem is.

I think you are misreading his intent.  I haven't seen any aspersion so
far.  I have seen an evident desire to decouple the policy questions (which
algorithms does one use and which key heirarchy does one use) from the
technical questions (what are the standard mechanisms are available for use).

Different user communities should be able to select for themselves which
algorithms they wish to use.  Similarly, different user communities should be
able to select which key heirarchy (if any, after all PGP is not a strict
heirarchy :-) they use.  It is the IETF way to only specify mechanisms and let
the various user communities decide the policy questions for themselves.

Please lets all keep the list discussions on the technical matter of what the
specifications say.  Other lists are more appropriate places for various folks
to debate policies.  Personally, I believe that different user communities
(e.g. Academia vs. Auto Industry) will have different security needs,
different security models, and different policy choices.  My personal goal is
to ensure that the right set of security mechanisms is available, not to
mandate any particular policy on any particular set of users.

Regards,

Ran
rja@cisco.com

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.  


Follow-Ups: References: