headers
Ted Lindgreen | 1 Dec 2007 08:40
Picon
Favicon

Re: NSEC3, version 13

[Quoting Sam Hartman, on Nov 30, 17:34, in "Re: NSEC3, version 1 ..."]

> However, since there are objections, I assume the chairs will also
> call for support;silence in the presence of objections is not rough
> consensus.

I share Sam's concern, I also think that silence does not suffice
to go forward.

NSEC3 is a very complicated protocol extention. Few people, even
in this WG, really understand the issues at hand, those who do,
should speak up and guarantee the rest of us that all issues are
now solved,

Regards,
-- ted

--
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
Olaf M. Kolkman | 1 Dec 2007 17:46
Picon
Favicon

Re: NSEC3, version 13


On 30Nov 2007, at 6:43 AM, Ólafur Guðmundsson /DNSEXT chair wrote:

> Please speak up if this change is of concern to you.
> If no one speaks up by Dec 7'th I will tell our AD the changes are
> fine.

So the change is that the basic-4 steps procedure was removed and  
replaced with text that amounts to "We'll solve this when we get to  
this".

For those who are not up to speed with the issue that is being  
addressed, the thread causing all this starts here:
http://ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00553.html

To me it is clear that the current text postpones dealing with the  
problem that starts with the premisses in Sam Weiler's observation:
    "but we aren't (as far as I can tell) requiring that an NSEC3- 
SHA256-capable resolver also support NSEC3-SHA1"

If the requirement to support old algorithms would exist, then the  
rollover is one that we currently understand.

Personally I could imagine that the introduction of a new hashing  
algorithm would be able to deal with that requirement: If all else  
fails using the blunt instrument of a flag date. Hopefully there is a  
more elegant way. Finding resolvers not supporting the old algorithm  
is unlikely but I appreciate the fact that a corner case remains a  
corner case and will need to be dealt with.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Lamb | 4 Dec 2007 01:32

dnssec-signzone/keygen /w seamless pkcs11 support - Part II

December 3, 2007

DNSSEC Enthusiasts-

Here is my second version of modifications to BIND for native PKCS11
HSM support (first released June 14 2007 on
 dnssec-deployment <at> shinkuro.com).  The vast majority of
 changes to BIND are restricted to one file
(lib/dns/opensslrsa_link.c).  Included are a number of HSM
utilities that should also work with any HSM with PKCS11
 support such as private key backup using C_Wrap/C_Unwrap.
 The archive is in fact a snapshot of  what IANA is using in its demo
DNSSEC system.   As there appears to be very little sample pkcs11 code
on the net, I hope it is in some way helpful to those of you
struggling with this. Feel free to use it or pieces of the code as you
please.  Contact me if you have any questions and I will try to help.

I. How to build and test PKCS11 HSM tools:

1. If you have not done so already, install and configure the PKCS11
library for your HSM.

If first time using this HSM this typically includes:
a. copying the pkcs11 library into a directory

b. enable the HSM

c. initialize the HSM

Otherwise:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Bligh | 4 Dec 2007 10:06
Picon

Re: NSEC3, version 13

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

--On 30 November 2007 00:43:49 -0500 "Ólafur Guðmundsson /DNSEXT chair" 
<ogud <at> ogud.com> wrote:

> Please speak up if this change is of concern to you.
> If no one speaks up by Dec 7'th I will tell our AD the changes are
> fine.

FWIW this text does NOT concern me and I think the changes are fine.

Alex

--
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
Sam Weiler | 4 Dec 2007 17:50

Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP

This draft does not address at least one issue raised in WGLC.  It 
also contains substantial changes made after the close of WGLC that 
have received too little attention from the WG.  Accordingly, I 
continue to oppose publication of this document[1].  I suggest that 
the IESG refer it back to the WG and, once a new document is advanced, 
issue a new IETF last call.

An example of an issue raised in WGLC (in August 2006) that I think 
should be addressed:

The document continues to use IETF Consensus as an allocation metric. 
That term is deprecated in 2434bis and should be replaced.  The editor 
appears to have agreed to make that change[2], and I've seen no 
follow-up discussion saying that shouldn't happen.

And an example of one of the changes that I think has received too 
little review:

The document allows templates to create IANA registries.  Is that 
altogether desirable?  Has the expert been given enough guidance to 
review such requests?

I have not attempted to do an exhaustive review of the 2929bis 
discussion, but I suspect there are other items in the above 
categories also.

On the positive side, I'm pleased that the document provides for 
permanently archived templates which can, in and of themselves, serve 
as adequate documentation of a typecode assignment.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Eastlake III Donald-LDE008 | 4 Dec 2007 23:24

RE: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP

Hi Sam,

It appears that, somehow, I overlooked message [2] below when I was
editing the document. Thanks for catching that. I'd be happy to make the
two changes agreed to: changing "who" to "whose" in one case (an error a
couple of other people have noticed) and changing "IETF Consensus" to
"IETF Review".

I believe that other changes you suggested were found by the WG Chair
not to have WG consensus.

Thanks,
Donald

-----Original Message-----
From: Sam Weiler [mailto:weiler <at> tislabs.com] 
Sent: Tuesday, December 04, 2007 11:51 AM
To: ietf <at> ietf.org
Cc: namedroppers <at> ops.ietf.org
Subject: Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System
(DNS) IANA Considerations) to BCP

This draft does not address at least one issue raised in WGLC.  It 
also contains substantial changes made after the close of WGLC that 
have received too little attention from the WG.  Accordingly, I 
continue to oppose publication of this document[1].  I suggest that 
the IESG refer it back to the WG and, once a new document is advanced, 
issue a new IETF last call.

An example of an issue raised in WGLC (in August 2006) that I think
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ólafur Guðmundsson /DNSEXT chair | 5 Dec 2007 18:44

Re: NSEC3, version 13

At 12:36 01/12/2007, Ted Lindgreen wrote:
>[Quoting Sam Hartman, on Nov 30, 17:34, in "Re: NSEC3, version 1 ..."]
>
> > However, since there are objections, I assume the chairs will also
> > call for support;silence in the presence of objections is not rough
> > consensus.
>
>I share Sam's concern, I also think that silence does not suffice
>to go forward.

We have IMHO a consensus on the document, what I need to know from
the working group member is if this change does affect their understanding
and expectations of the protocol.
This is a form of consensus call and should be just fine as the
explicit way to judge the consensuses is expressed.

>NSEC3 is a very complicated protocol extention. Few people, even
>in this WG, really understand the issues at hand, those who do,
>should speak up and guarantee the rest of us that all issues are
>now solved,

This is not a fair request without you saying what you mean by
"guarantee the rest of us that all issues are now solved".
Is this a guarantee that the expert has to pay penalty if she/he is wrong?
Did you mean to say "assert that he/she knows of NO issues with the 
current specification".

         Olafur

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ted Lindgreen | 5 Dec 2007 21:08
Picon
Favicon

Re: NSEC3, version 13

[Quoting =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair, on Dec  5, 19:19,
in "Re: NSEC3, version 1 ..."]

> This is not a fair request without you saying what you mean by
> "guarantee the rest of us that all issues are now solved".
> Is this a guarantee that the expert has to pay penalty if she/he is wrong?
> Did you mean to say "assert that he/she knows of NO issues with the 
> current specification".

I meant the latter,
-- ted

--
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
roy | 6 Dec 2007 02:47
Picon
Favicon

Re: NSEC3, version 13

Ted Lindgreen wrote on 11/30/2007 11:40:29 PM:

> [Quoting Sam Hartman, on Nov 30, 17:34, in "Re: NSEC3, version 1 ..."]
> 
> > However, since there are objections, I assume the chairs will also
> > call for support;silence in the presence of objections is not rough
> > consensus.
> 
> I share Sam's concern, I also think that silence does not suffice
> to go forward.
> 
> NSEC3 is a very complicated protocol extention. Few people, even
> in this WG, really understand the issues at hand, those who do,
> should speak up and guarantee the rest of us that all issues are
> now solved,

I am confident all issues are now solved. Nothing has changed in the 
normative text part of the draft for a while now (not counting the 
occasional typo).

The text that changed was section 12.1.3, which had a 4 step gradual 
transition process for zone administrators to gradually introduce NSEC3 
records with a new hash algorithm. 

Without a gradual introduction of NSEC3 records, an administrator needs to 
change the hash algorithm and the signature algorithm in a single SOA 
serial version increase (i.e. an instant transition for lack of better 
terminology). That might be a bit problematic for highly volatile or very 
large zones though I do not expect that this transition would happen 
frequently.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Koch | 8 Dec 2007 08:07
Picon
Favicon

Re: NSEC3, version 13

On Sat, Dec 01, 2007 at 05:46:15PM +0100, Olaf M. Kolkman wrote:

> So the change is that the basic-4 steps procedure was removed and  
> replaced with text that amounts to "We'll solve this when we get to  
> this".

I agree with the changes proposed for -13 in Roy's message dated 30 NOV.

> problem that starts with the premisses in Sam Weiler's observation:
>    "but we aren't (as far as I can tell) requiring that an NSEC3- 
> SHA256-capable resolver also support NSEC3-SHA1"

This is one underlying assumption, although it doesn't _have_ to be
that way.  The new algorithm could as well mean "SHA256 or SHA1".
Theoretically this would allow a downgrade attack, but that could be
mitigated by doing a double transition (where the intermediate state
might even be infinitesimally small):
	NSEC3-SHA1 -> NSEC3-SHAng-or-SHA1 -> NSEC3-SHAng
Alternatively, for the transition phase, both hash algs could be signalled
in the DS RR.  Either of these could again have corner cases, but locating
and arguing them is not my point.  I am confident that the WG as a whole
understands signalling and rollover well enough to address the issue
once it becomes necessary. Hash algorithm is expected to be a _rare_
event, as opposed to key rollover, so extra manual intervention or
timing constraints appear acceptable IMHO.
The exact scheme will also depend on the operational environment at that
future date and thus could be dealt with later better anyway.

> Anyhow, as far as I am concerned, this is a corner case that can be  
> dealt with later. The current text does sufficiently flag this is an
(Continue reading)

Permalink | Reply | 0 comments |

Gmane