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

[IPSECKEY] Security Considerations



I sent Michael a bunch of comments on the current draft yesterday.
Most of them were dumb little editorial stuff.  The one really
substantial comment was about the Security Considerations section.  I
don't think that what we have there now will fly, it fails the hurdle
as stated in ID-nits:

"Must have meaningful exploration of security issues raised by
 proposal, should include both risks and description of solutions or
 workarounds."

I agreed to help Michael on fixing this (other volunteers would of
course be welcome, nay, beseeched), but there's one point we need to
clarify with the WG first:

Is it the intention of this WG that the IPSECKEY RR be useful in an
environment which does not (somehow) provide data origin
authentication and data integrity protection for the IPSECKEY RR?
Please note that I am trying -not- to make this explictly dependent on
DNSSEC, the issue here is what services we require from the
environment, not what specific mechanism provides those services.

If the answer is "no, the WG doesn't expect IPSECKEY to be useful
without data origin authentication and data integrity protection for
the IPSECKEY RR", then the security considerations stuff is just a
matter of writing up some stuff we already understand.  If, however,
the answer is "yes", then somebody needs to explain how and why it
makes sense to trust keys that one gets without these protections,
because we need to put that explanation into the draft.

My (personal, private) take is that the answer to the question is
"no", but that's for the WG as a whole to decide.

Please also note that fixing up the Security Considerations section
will probably involve evaluating SHOULDs and MUSTs elsewhere in the
draft to make sure that they're consistant with what we've written.
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.