Subject: [IPSECKEY] Security Considerations

From: Rob Austein <[email-masked]>
Date: Mon, 19 May 2003 14:26:14 -0400

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 [email-masked] list.
Email to [email-masked] to be removed.

---

From: Jean-Jacques Puig <[email-masked]>
Date: Tue, 20 May 2003 09:49:29 +0200

> authentication and data integrity protection for the IPSECKEY RR?

My opinion is also "no" (well, I mean it is not 'my' intention "that the
IPSECKEY RR etc."). But I would be interested in the explanations of
someone who would say "yes" here (pure curiosity :).

> environment, not what specific mechanism provides those services.

Agree. Obviously, DNSSEC is not the only solution available here (it may
depend on the use of the RR, which is not covered by the draft). I made
the cut and paste for the WG to discuss on the real thing:

4. Security Considerations

|  This entire memo pertains to the provision of public keying material
|  for use by key management protocols such as ISAKMP/IKE (RFC2407) [7].

|  Implementations of DNS servers and resolvers SHOULD take care to make
|  sure that the keying material is delivered intact to the end
|  application.  The use of DNSSEC to provide end-to-end integrity
|  protection is strongly encouraged.

May be 'strongly encouraged' is a bit... strong :). Why not something
like: 

%  Implementations of DNS servers and resolvers SHOULD take care to make
%  sure that the keying material is delivered intact to the end
%  application. End to end integrity can be achieved, for instance,
%  through the use of DNSSEC [8].

|  The semantics of this record is outside of the scope of this
|  document, so no advice for users of this information is provided.
|  Any user of this resource record MUST carefully document their trust
|  model, and why the trust model of DNSSEC is appropriate.

Well, anyway, current SC section looks good. I don't think we have a big
issue here unless WG globally disagree on the importance of integrity
and data origin authentication.

--
Jean-Jacques Puig
-

---

From: Jean-Jacques Puig <[email-masked]>
Date: Tue, 20 May 2003 21:22:24 +0200

> someone who would say "yes" here (pure curiosity :).

Sorry, I realized reading `comments and nits` from Mr Austein that I
possibly misunderstood his words.

IMHO, express an 'intent' is not the same as to 'order': the former
expresses itself with SHOULD while the later expresses with MUST.
Rephrasing my answer:

"no, it is not my intention that the IPSECKEY RR ... which does not
(somehow) ... for the IPSECKEY RR BUT I don't care if someone uses this
RR in such an environment."

> %  through the use of DNSSEC [8].

This is where we disagree I think. SHOULD is perfectly suitable here
(IMHO), and MUST would be more than expressing an intent: it would
express a requirement.

2119:
1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

I don't think it is a up to the wg to make DNSSEC or any other mecanism
mandatory. We surely can provide advices though.