headers
Olaf Kolkman | 1 Apr 2004 08:35
Picon
Favicon

DNSEXT list policy


- List Purpose

  namedroppers <at> ops.ietf.org is the mailing list for the IETF DNSEXT
  working group.  

  See <http://www.ietf.org/html.charters/dnsext-charter.html> for the
  wg charter.  Messages should be on topics appropriate to the dnsext
  wg, which are various discussion of the DNS protocols or
  administrivia of the WG itself.

- Specific items that are not not appropriate for posting

  Calls for papers, announcements of events not directly relevant to
  the DNS protocols, etc. are not appropriate.  

  Discussion of problems with particular implementations,
  announcements of releases, sites' misconfigurations, pleas for help
  with specific implementations, etc.  should be done on mailing lists
  for the particular implementations.

  There is a working group for dns operational practice, DNSOP, whose
  charter can be found at
  <http://www.ietf.org/html.charters/dnsop-charter.html>. Items
  relevant to the DNSOP charter are to be discussed on the DNSOP
  mailinglist.

  Discussion about the quality of implementations is outside the scope
  of this list.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Fort | 2 Apr 2004 15:37
Picon
Favicon

KROd 1.0rc2

The IDsA project (http://idsa.irisa.fr/index.php?lang=en) has just the 
second release candidate
for KROd 1.0.
KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be
used to "DNSSECify" normal DNS zones.
KROd is still an experimental product and as such shouldn't be used in 
production
environment.

More informations/downloads can be found here:
    http://idsa.irisa.fr/index.php?page=kro&lang=en

--

-- 
Fort David, Projet IDsA
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tél: +33 (0) 2 99 84 71 33

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 2 comments |
headers
bmanning | 3 Apr 2004 00:04

Re: KROd 1.0rc2

On Fri, Apr 02, 2004 at 03:37:30PM +0200, David Fort wrote:
> The IDsA project (http://idsa.irisa.fr/index.php?lang=en) has just the 
> second release candidate
> for KROd 1.0.
> KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be
> used to "DNSSECify" normal DNS zones.
> KROd is still an experimental product and as such shouldn't be used in 
> production
> environment.
> 
> More informations/downloads can be found here:
>    http://idsa.irisa.fr/index.php?page=kro&lang=en
> 
> -- 
> Fort David, Projet IDsA
> IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
> Tél: +33 (0) 2 99 84 71 33

	very experimental....

	"... unable to find the file or directory named
	/local/idsa/code/kro/KROd-1.0tc2.tar.bz2
	Check the name and try again."

--bill

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
(Continue reading)

Permalink | Reply | 0 comments |
headers
bmanning | 3 Apr 2004 00:11

Re: KROd 1.0rc2

On Fri, Apr 02, 2004 at 03:37:30PM +0200, David Fort wrote:
> KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be
> used to "DNSSECify" normal DNS zones.
> KROd is still an experimental product and as such shouldn't be used in 
> production
> environment.
> 
> More informations/downloads can be found here:
>    http://idsa.irisa.fr/index.php?page=kro&lang=en
> 
> -- 
> Fort David, Projet IDsA

	Ah... reverting to the more primative (but in many ways, more flexable)
	native FTP....

ftp> ls
227 Entering Passive Mode (131,254,254,10,179,49)
150 Opening ASCII mode data connection for /bin/ls.
total 2656
drwxr-xr-x   2 4779     29016       8192 Mar 11 16:36 .
drwxr-xr-x  10 4779     29016       8192 Feb 16 12:48 ..
-rw-r--r--   1 4779     29016     127417 Feb 16 12:49 DNSsecToolkit-1.0-rc1.tar.gz
-rw-r--r--   1 4779     29016     237854 Feb 23 13:58 DNSsecToolkit-1.0-rc2.tar.gz
-rw-r--r--   1 4779     29016     325688 Mar  1 16:21 DNSsecToolkit-1.0-rc3.tar.gz
-rw-r--r--   1 4779     29016     325963 Mar 11 09:55 DNSsecToolkit-1.0-rc4.tar.gz
-rw-r--r--   1 4779     29016     176701 Feb 16 12:49 KROd-1.0rc1.tar.gz
-rw-r-----   1 4779     29016     129864 Mar 11 16:37 KROd-1.0rc2.tar.bz2
226 Transfer complete.
ftp> get KROd-1.0rc2.tar.bz2
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Fort | 5 Apr 2004 18:23
Picon
Favicon

Re: KROd 1.0rc2

bmanning <at> vacation.karoshi.com wrote:

>On Fri, Apr 02, 2004 at 03:37:30PM +0200, David Fort wrote:
>  
>
>>KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be
>>    
>>
>  
>
[...]

>-rw-r--r--   1 4779     29016     176701 Feb 16 12:49 KROd-1.0rc1.tar.gz
>-rw-r-----   1 4779     29016     129864 Mar 11 16:37 KROd-1.0rc2.tar.bz2
>226 Transfer complete.
>ftp> get KROd-1.0rc2.tar.bz2
>local: KROd-1.0rc2.tar.bz2 remote: KROd-1.0rc2.tar.bz2
>227 Entering Passive Mode (131,254,254,10,112,150)
>550 KROd-1.0rc2.tar.bz2: Permission denied.
>  
>
Corrected

--

-- 
Fort David, Projet IDsA
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tél: +33 (0) 2 99 84 71 33

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 6 Apr 2004 16:31
Picon
Favicon

I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Threat Analysis Of The Domain Name System
	Author(s)	: D. Atkins, R. Austein
	Filename	: draft-ietf-dnsext-dns-threats-07.txt
	Pages		: 16
	Date		: 2004-4-5
	
Although the DNS Security Extensions (DNSSEC) have been under
   development for most of the last decade, the IETF has never written
   down the specific set of threats against which DNSSEC is designed to
   protect.  Among other drawbacks, this cart-before-the-horse situation
   has made it difficult to determine whether DNSSEC meets its design
   goals, since its design goals are not well specified.  This note
   attempts to document some of the known threats to the DNS, and, in
   doing so, attempts to measure to what extent (if any) DNSSEC is a
   useful tool in defending against these threats.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-07.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Rose | 6 Apr 2004 18:10
Favicon

Q31: Validator behavior for islands of security

Question:  What is default behavior when a validator cannot get a secure
entry point into an island of security?

In proto-05 section 5.1, there is the discussion on the resolution process
and islands of security (or self-signed zones with no secure delegation).
The last sentence in the first paragraph reads:

     If a validator cannot obtain such a key, it will have
     to choose whether to accept the unvalidated responses
     or not based on local policy.

The suggested change:

	If a validator cannot obtain such a key, it
      SHOULD switch to operating as if the zones
	in the island of security are unsigned.

Background:
RFC 2535 mentions islands of security, but gives no specific handling
instructions.  RFC
3090 (DNS Security Extensions on Zone Status) section 1.2 states that "The
only way in which a DNSSEC resolver will come to trust any data from this
island is if the resolver is pre-configured with the zone key(s)... Other
resolvers (not so configured) will recognize this island as unsecured."
This change attempts to bring the spec in line (and strengthen) with RFC
3090.

This question is not an attempt to raise the same topics as DNSSECbis Q28 on
how a validator and resolver should act with regards to unsigned or invalid
signatures.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rob Austein | 6 Apr 2004 18:47

Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt

For those who have not been following the exciting details in the
draft tracker: this is the final version of this draft, which
addresses the last of the issues that came up during IETF last call
and IESG review.  As far as the authors know, we are done, and we
expect formal IESG publication approval within a few days.

We don't think any of the recent changes are controversial, but:

a) If anyone thinks there's a show-stopping problem with the changes,
   speak up now;

b) No new issues, please, it's past time to ship this puppy.

Change logs available at http://www.hactrn.net/ietf/dns/threats/

--Rob and Derek

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 4 comments |
headers
Masataka Ohta | 7 Apr 2004 13:16
Picon

Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt

Rob Austein wrote:

> For those who have not been following the exciting details in the
> draft tracker: this is the final version of this draft, which
> addresses the last of the issues that came up during IETF last call
> and IESG review.  As far as the authors know, we are done, and we
> expect formal IESG publication approval within a few days.

Can someone explain why "Name Chaining attacks" are
harmful?

As far as I understand, name chaining is, first, to let
the victim access a name of attackers choice and, secondly,
to let the victim access names of attackers choice.

So, if the attacker can control the first name, why it
is more harmful that the attacker can control the
subsequent accesses?

If the attacker can control the first name and the victim
is not protected from cache poisoning, the attacker can
inject a lot of false information with the first access
that I can see no point of chaining.

					Masataka Ohta

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Scott Rose | 7 Apr 2004 20:36
Favicon

RE: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt

I think the new version is good.  From my reading of the draft "name
chaining" sounds like a slightly better term for that class of attacks.

I do not see any show-stopper problems.

Scott

> -----Original Message-----
> From: owner-namedroppers <at> ops.ietf.org
> [mailto:owner-namedroppers <at> ops.ietf.org]On Behalf Of Rob Austein
> Sent: Tuesday, April 06, 2004 12:48 PM
> To: namedroppers <at> ops.ietf.org
> Subject: Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt
>
>
> For those who have not been following the exciting details in the
> draft tracker: this is the final version of this draft, which
> addresses the last of the issues that came up during IETF last call
> and IESG review.  As far as the authors know, we are done, and we
> expect formal IESG publication approval within a few days.
>
> We don't think any of the recent changes are controversial, but:
>
> a) If anyone thinks there's a show-stopping problem with the changes,
>    speak up now;
>
> b) No new issues, please, it's past time to ship this puppy.
>
> Change logs available at http://www.hactrn.net/ietf/dns/threats/
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane