headers
Olaf Kolkman | 1 May 2006 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
bert hubert | 7 May 2006 00:44
Picon
Favicon
Gravatar

Re: should a pure recursor know about localhost/1.0.0.127.in-addr.arpa?

On Tue, Apr 11, 2006 at 03:05:28PM +0000, Paul Vixie wrote:
> (to be able to resolve their own names when their transit pipe is down.)  as
> attractive as it is to do a "pure" nameserver with nearly zero config, it's
> unrealistic in today's polluted local namespaces.

Fixed in 3.1-pre1,
http://doc.powerdns.com/changelog.html#CHANGELOG-RECURSOR-3-1 , thanks.

--

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
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 | 0 comments |
headers
Ólafur Guðmundsson /DNSEXT co-chair | 8 May 2006 17:41

Standardize RSA/SHA256 ?


Dear colleagues

The Working group has had a document for the last few months that
defines a new DNSKEY algorithm RSA/SHA256. Discussion on this
document has been non existent.

The chairs would like to ask the working group following question:
Is there support in the working group to add a new RSA algorithm
to the list of supported algorithms?

The benefit is SHA256 is stronger digest than the SHA1 that is in use
today. Given that DNSSEC signatures are over structured data, it is
not known how much effort is needed to create RRSET that matches
existing signature for a particular name, type and class.
Further consideration is the fact that DNSSEC signatures
have a limited lifetime, restricting the window that a forged RRSET
can be used by DNSSEC validating resolvers.

The alternative to defining RSA/SHA256 now is to wait for efforts to
standardize new digest algorithms by NIST which will take 4-5 years.

Please give your chairs guidance on how to proceed, if there is
sufficient support (minimum of 5 people) for defining RSA/SHA256
we will start a formal last call.

	Olafur & Olaf 

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

Permalink | Reply | 28 comments |
headers
Russ Mundy | 8 May 2006 18:24

Re: Standardize RSA/SHA256 ?

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

I strongly support the need for standarization of this algorithm and
incorporation of it into the set of DNS RFCs.

Russ Mundy

On 5/8/06 at 11:41 AM -0400, Ólafur  Gu›mundsson /DNSEXT co-chair
<ogud <at> ogud.com> wrote: 

>
>
>Dear colleagues
>
>The Working group has had a document for the last few months that
>defines a new DNSKEY algorithm RSA/SHA256. Discussion on this
>document has been non existent.
>
>The chairs would like to ask the working group following question:
>Is there support in the working group to add a new RSA algorithm
>to the list of supported algorithms?
>
>The benefit is SHA256 is stronger digest than the SHA1 that is in use
>today. Given that DNSSEC signatures are over structured data, it is
>not known how much effort is needed to create RRSET that matches
>existing signature for a particular name, type and class.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francis Dupont | 8 May 2006 19:44

Re: Standardize RSA/SHA256 ?

 In your previous mail you wrote:

   Please give your chairs guidance on how to proceed, if there is
   sufficient support (minimum of 5 people) for defining RSA/SHA256
   we will start a formal last call.

=> I support

Francis.Dupont <at> point6.net

--
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 | 0 comments |
headers
Rob Austein | 8 May 2006 19:52

Re: Standardize RSA/SHA256 ?

At Mon, 08 May 2006 11:41:23 -0400, Ólafur Guðmundsson wrote:
> 
> Please give your chairs guidance on how to proceed, if there is
> sufficient support (minimum of 5 people) for defining RSA/SHA256
> we will start a formal last call.

I support standardizing RSA/SHA256

(As the chairs no doubt remember, I threatened to write a draft
proposing this, but somebody else kindly wrote it first....)

--
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 | 0 comments |
headers
Mike StJohns | 8 May 2006 20:18

Re: Standardize RSA/SHA256 ?

Um...

OK...  I don't think this is the right question 
or set of questions to ask.  Obviously stronger is good but:

1) Should we standardize RSA/SHA256?   - Yes
2) Should we standardize DSA/SHA256?  - No comment?
3) Should we deprecate RSA/SHA1?  Yes, but what does that mean?
4) Should RSA/SHA256 be Mandatory to Implement 
(at both the signing side and the resolver side)?  Yes.
5) Should the root (and/or lower trust anchors) 
be signed with RSA/SHA256 in addition to or in 
replacement of RSA/SHA1? - Well, that brings in 
the whole question of algorithm rollover...and "downgrade attacks"  *sigh*

So while I would agree that this might be "A GOOD 
THING" - I think its handwaving to just say yes 
to RSA/SHA256 without dealing with all the other things.

DNSSEC has gotten consistently more complex - the 
addition of NSEC3 and the interactions with NSEC 
still don't give me warm fuzzies.  After many 
long sessions with the folks that should know how 
this should all work I still don't have a good 
feeling about using more than one signature 
algorithm in a trust chain.  How do 
NSEC/NSEC3/RSASHA1/RSASHA256 all play together?

The specific document has some issues as well - 
specifically dealing with RSA DNSKEY records - it
(Continue reading)

Permalink | Reply | 3 comments |
headers
Internet-Drafts | 8 May 2006 21:50
Picon
Favicon

I-D ACTION:draft-ietf-dnsext-rollover-requirements-01.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		: Requirements related to DNSSEC Trust Anchor Rollover
	Author(s)	: S. Crocker, et al.
	Filename	: draft-ietf-dnsext-rollover-requirements-01.txt
	Pages		: 11
	Date		: 2006-5-8
	
Every DNS security-aware resolver must have at least one Trust Anchor
to use as the basis for validating responses from DNS signed zones.
For various reasons, most DNS security-aware resolvers are expected
to have several Trust Anchors.  For some operations, manual
monitoring and updating of Trust Anchors may be feasible but many
operations will require automated methods for updating Trust Anchors
in their security-aware resolvers.  This document identifies the
requirements that must be met by an automated DNS Trust Anchor
rollover solution for security-aware DNS resolvers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rollover-requirements-01.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 | 3 comments |
headers
Wes Hardaker | 8 May 2006 22:25

Re: Standardize RSA/SHA256 ?

>>>>> On Mon, 08 May 2006 11:41:23 -0400, ogud <at> ogud.com (Olafur Gudmundsson) said:

Olafur> The alternative to defining RSA/SHA256 now is to wait for efforts to
Olafur> standardize new digest algorithms by NIST which will take 4-5 years.

I believe we should standardize it now rather than wait.  If we
believe that a particular algorithm will likely used in the future,
and I believe this one will be, then I don't see the point in waiting
to define it later if we have the time and energy now.  More
importantly, I think it would be detrimental to delay defining it now
assuming it will be defined at some point.

The only way I think not defining it now is wise is if we're uncertain
that it'll be selected for future use.
--

-- 
Wes Hardaker
Sparta, Inc.

--
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 | 0 comments |
headers
Ólafur Guðmundsson /DNSEXT co-chair | 8 May 2006 22:51

Re: Standardize RSA/SHA256 ?

At 14:18 08/05/2006, Mike StJohns wrote:
>Um...
>
>OK...  I don't think this is the right question 
>or set of questions to ask.  Obviously stronger is good but:
>
>1) Should we standardize RSA/SHA256?   - Yes
>2) Should we standardize DSA/SHA256?  - No comment?
>3) Should we deprecate RSA/SHA1?  Yes, but what does that mean?
>4) Should RSA/SHA256 be Mandatory to Implement 
>(at both the signing side and the resolver side)?  Yes.
>5) Should the root (and/or lower trust anchors) 
>be signed with RSA/SHA256 in addition to or in 
>replacement of RSA/SHA1? - Well, that brings in 
>the whole question of algorithm rollover...and "downgrade attacks"  *sigh*
>
>So while I would agree that this might be "A 
>GOOD THING" - I think its handwaving to just say 
>yes to RSA/SHA256 without dealing with all the other things.

Thanks Mike for your list of follow up questions,
few comments:
Q2: is a different question and does not belong here, but this is a related
         question. As far as I can tell right now no-one has shown any interest
         in using DSA when deploying DNSSEC. As long as that is the case the
         question about DSA/SHA256 should be asked at the same time as the
         kill DSA question is raised.

Q3: My personal opinion not speaking as a chair:
         If RSA/SHA256 is specified then RSA/SHA1 should be
(Continue reading)

Permalink | Reply | 2 comments |

Gmane