Subject: [IPSECKEY] the -01 draft

From: Michael Richardson <[email-masked]>
Date: Wed, 07 May 2003 16:19:40 -0400

-----BEGIN PGP SIGNED MESSAGE-----

I'm going to repeat the Security Considerations section here:

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.

|  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.

===

Secondly, is there agreement that "DNSSEC" generally includes use of
TSIG, or should this be explicitely stated? It seems like overspecification
to me.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 7 May 2003 23:47:23 +0200 (CEST)

> TSIG, or should this be explicitely stated? It seems like overspecification

I think the resolution process should be stated.

in draft-ietf-secsh-dns we wrote:

  "Clients that do not validate the DNSSEC signatures themselves MUST
   use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7],
   between themselves and the entity performing the signature
   validation."

	jakob
-

---

From: Rob Austein <[email-masked]>
Date: Wed, 07 May 2003 17:50:43 -0400

> TSIG, or should this be explicitely stated? It seems like overspecification

One could make a case either way, but the "DNS Threats" document[1]
took the position that TSIG is not part of "DNSSEC" per se, and I
think the DNSSECbis editorial team[2] came to the same conclusion.

Of course, I'm a co-author of [1] and a member of [2], so I may just
be reporting my own (internally consistant) confusion.
-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 May 2003 20:49:22 -0400

>>>>> "Jakob" == Jakob Schlyter <[email-masked]> writes:
    Jakob> I think the resolution process should be stated.

    Jakob> in draft-ietf-secsh-dns we wrote:

    Jakob>   "Clients that do not validate the DNSSEC signatures themselves
    Jakob>   MUST 
    Jakob>    use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7],
    Jakob>    between themselves and the entity performing the signature
    Jakob>    validation."

  I'd rather write:
      Clients that do not validate the DNSSEC signatures themselves
      MUST communicate with a recursive resolver that does DNSSEC resolution
      using either a secure channel: local to the host, or via a TSIG
      or SIG(0) with another host.

-

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 08 May 2003 12:43:38 +0200

>       or SIG(0) with another host.

This text imply that DNSSEC is required for IPSECKEY to work, which I
believe would be a mistake.

I believe IPSECKEY is useful without DNSSEC, just as long as the data
is properly secured.

DNSSEC may have been a hidden assumption in the mind set of people
related to this work, but I see no technical justification for it.

Preventing IPSECKEY to work with secure DNS systems that aren't based
on DNSSEC would be unfortunate.

I think Jakob's proposed text is better.

-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 May 2003 14:32:56 -0400

-----BEGIN PGP SIGNED MESSAGE-----

Simon, I see your point in the text that I wrote. Not my intention to
restrict it. Jakob's text still implies that the signatures must be checked,
which is not the case if one knows one is pulling it from a local server
which may have an authoritative on disk source.

How about:
    The IPSECKEY resource record contains information that MUST be
    communicated to the end client in an integral fashion - i.e. free
    from modification. The form of this channel is up to the consumer
    of the data. It may be end-to-end DNSSEC validation, a TSIG or SIG(0)
    channel to another secure source, a secure local channel on the
    host, or some combination of the above.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 08 May 2003 20:56:15 +0200

>     host, or some combination of the above.

Sounds good.

There must be a trust relationship between the client and the server,
so the client is able to trust that the data it is using really was
unmodified.  Perhaps this is obvious, though.

Thanks!

-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 May 2003 15:10:15 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
    Simon> There must be a trust relationship between the client and the
    Simon> server, so the client is able to trust that the data it is using
    Simon> really was unmodified.  Perhaps this is obvious, though.

  My impression is that "Security Considerations" sections are really there
to make sure that the obvious is clearly stated for all.

  The text is now:

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

   The IPSECKEY resource record contains information that MUST be
   communicated to the end client in an integral fashion - i.e.  free
   from modification.  The form of this channel is up to the consumer of
   the data - there must be a trust relationship between the end
   consumer of this resource record and the server.  This relationship
   may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to
   another secure source, a secure local channel on the host, or some
   combination of the above.

   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, if that is
   the secure channel used.

Chairs, are there further issues with the -01 document?

-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 May 2003 18:30:28 -0400

I noticed that email out of my system was generally blocked.
ipseckey has two subcribers at @nic.mx, for which TLS was attempted,
and it was hanging - sendmail needed -9 to boot it.

I have rebuilt my sendmail with the right option to have it consult
on whether or not to do TLS, and disabled it for nic.mx. Email
should get unblocked slowly.