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

No Subject



From owner-ipseckey@lox.sandelman.ottawa.on.ca Tue May 20 15: 37:35 2003
Received: from expansionpack.xtdnet.nl (mail.xtdnet.nl [193.110.157.5])
	by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KJb9i14424;
	Tue, 20 May 2003 15:37:34 -0400 (EDT)
Received: from mail.xtdnet.nl (mail.xtdnet.nl [193.110.157.5])
	by expansionpack.xtdnet.nl (8.12.8/8.11.6) with ESMTP id h4KJYvDJ010178
	(using TLSv1/SSLv3 with cipher EDH-DSS-DES-CBC3-SHA (168 bits) verified NO);
	Tue, 20 May 2003 21:34:57 +0200
Date: Tue, 20 May 2003 21:34:57 +0200 (MET DST)
From: Paul Wouters <paul@xtdnet.nl>
To: hugh@xisp.net
cc: ipseckey@sandelman.ca, gnu@toad.com, mcr@sandelman.ca,
    weiler@watson.org, sra+ipseckey@hactrn.net,
    design@lists.freeswan.org
Subject: Re: [Design] Security Considerations for IPSECKEY
In-Reply-To: <200305191954.h4JJsJHX008066@road.toad.com>
Message-ID: <Pine.LNX.4.44.0305202130430.8630-100000@expansionpack.xtdnet.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner: Found to be clean
Resent-To: ipseckey@sandelman.ca
Resent-Date: Tue, 20 May 2003 16:47:14 -0400
Resent-From: Michael Richardson <mcr@marajade.sandelman.ottawa.on.ca>

On Mon, 19 May 2003, Hugh Daniel wrote:

>   If the users (or system/network admins) "threat model" policy
> causes the IPSECKEY RR (and other RR's) to be integrity/authentication
> checked then the check it's self has to be securely delivered to the
> end user/program.
> 
>   In the current Internet it is quite possible that network designers
> will try to create networks where DNSsec caching and/or validation
> will happen on hosts that are across un-secured local LAN's from the
> end user/program.  Such networks are fundamentally only as secure as
> the first issue case (raw DNS that protects only against passive
> attacks).

I would add to this that insecurely using a dnssec resolver does has
one problem, it gives a false sense of security. Is the application
relaying on the insecure "ad" bit? Is it relying on not getting a servfail?
I seriously hope that running your own (caching) recursive resolver
becomes best current practice or even a mandatory part of dnssec (MUST HAVE)

Paul 

-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.