headers
David Meyer | 2 Nov 2004 16:09

updated DNSOP agenda for IETF 61


Domain Name System Operations (dnsop)

MONDAY, November 8, 2004 (1300-1500)
=====================================

CHAIR(s): David Meyer <dmm <at> 1-4-5.net>
          Rob Austein <sra <at> isc.org>

AGENDA

 o Administriva						 5 minutes

   - Mailing list: majordomo <at> lists.uoregon.edu
     subscribe dnsop

   - Scribe?

   - Blue Sheets

 o Agenda Bashing					 5 minutes
   Meyer                                           

 o Review and status of work items			 

   Active Drafts
   -------------
   draft-ietf-dnsop-dnssec-operational-practices-02.txt   5 minues
    Kolkman et al
   draft-ietf-dnsop-inaddr-required-05.txt                5 minutes
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Chown | 8 Nov 2004 19:42
Picon
Favicon

On dontpublish-unreachables

Hi,

Regarding the raising of draft-ietf-dnsop-dontpublish-unreachable-03, it
was asked where ureachables might be placed in the DNS, I think one area 
where this was suggested as possible was by some people in the IPv6 WG 
where the new "guaranteed" unique ULAs may be published since (in theory) 
there is no ambiguity with the ULAs.

I agree with Alain that this still seems undesirable.

The 03 version talks about deprecated IPv6 items, such as site-locals
and IPv4 compatibles.

(Also I see no 04 version at watersrings:
http://www.watersprings.org/pub/id/draft-ietf-dnsop-dontpublish-unreachable-03.txt, is there
an 04 that they didn't pick up since Feb'02?)

--

-- 
Tim
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 1 comment |
headers
Rob Austein | 8 Nov 2004 22:09

Re: On dontpublish-unreachables

At Mon, 8 Nov 2004 18:42:05 +0000,  Tim Chown wrote:
> 
> (Also I see no 04 version at watersrings:
> http://www.watersprings.org/pub/id/draft-ietf-dnsop-dontpublish-unreachable-03.txt,
> is there an 04 that they didn't pick up since Feb'02?)

-04 is just the "this draft has expired" tombstone.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 0 comments |
headers
Samuel Weiler | 9 Nov 2004 21:51

Comments on key rollover req. draft

This document has a number of unjustified and mutually exclusive
requirements.  To wit:

   From Section 2: "... the child zone must contact its parent zone
   and must notify it about the KSK change(s)."  Some proposed schemes
   involve the parent polling the child.  Those schemes may be
   unwise, but "must" seems overbroad and certainly unjustified by
   the text in this document.

   Later in section 2: "the security of these communications [in
   manual rollovers] is out of scope of DNSSEC."  Not necessarily.  A
   child might manually add new keys, intending that they be
   authenticated in-band, then contact the parent out-of-band to
   trigger the update (a process that may not need to be secured),
   then the parent fetches the key keys in-band.

   In section 3, I'm not sure what is meant by "Every RR MUST be
   verifiable at any time..."  In any case, I hope "every RR" does not
   include "every RRSIG" -- I'd like to allow publication of RRSIGs
   even when the DNSKEYs that created them aren't available.

   Section 4 has an unjustified requirement for in-band
   authentication: "Every exchanged message MUST be authenticated and
   the authentication tool MUST be a DNSSEC tool..."  Unless we're
   limiting this document's scope to in-band rollover, this is grossly
   inappropriate.

   The next paragraph of section 4 has another unjustified
   requirement: "... a child zone,... MUST notify its parent
   zone...".  Why is this document trying to disallow parent polling?
(Continue reading)

Permalink | Reply | 16 comments |
headers
Scott Rose | 10 Nov 2004 16:13
Favicon

RFC 2541 and dnssec operational practices draft

As mentioned in the WG meeting:  Looking back on the RFC2541 draft, it
mostly deals with key generation and lifetime requirements.
draft-ietf-dnsop-dnssec-operational-practices-02 covers much more ground
with operation procedures for key rollovers.

RFC 2541 also gives hard numbers for key length minimums and lifetimes,
which may not always hold in different deployments.  For example:
Transaction security keys have a suggesed max lifetime of 36 days.  It also
only addresses RSA/MD5 which is now not recommeded for DNSSEC.  So while a
initial document for DNSSEC deployment, it does not address several key
items in maintaining a secure tree.

I would therefore like to see the new draft obsolete RFC2541 and progress as
an informational RFC.

Scott

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 2 comments |
headers
Olaf M. Kolkman | 10 Nov 2004 16:57
Picon
Favicon

Re: RFC 2541 and dnssec operational practices draft

Scott Rose wrote:

>
>I would therefore like to see the new draft obsolete RFC2541 and progress as
>an informational RFC.
>
>  
>
Where 'the new draft' refers to dnssec-operational-practices.

Miek, Rip and myself are looking at how we can merge the relevant parts. 
If the WG thinks this is a good idea we'll proceed.  (That is, please 
shout "STOP" asap if you do not want us to put it in operational 
practices. :-) )

--Olaf
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 1 comment |
headers
Scott Rose | 10 Nov 2004 17:06
Favicon

RE: RFC 2541 and dnssec operational practices draft

> -----Original Message-----
> From: Olaf M. Kolkman [mailto:olaf <at> ripe.net]
>
> Miek, Rip and myself are looking at how we can merge the relevant parts.
> If the WG thinks this is a good idea we'll proceed.  (That is, please
> shout "STOP" asap if you do not want us to put it in operational
> practices. :-) )
>

I am not yelling stop yet.  I would suggest dropping all language regarding
specific key lengths and lifetimes.  Or at least make it clear they are
recommend values and can be superceeded by local policy.  It would also be
nice to find a good reference to back up any recommended values - especially
when it comes to key length.  Some people take that serious for some strange
reason ;-)

Scott

> --Olaf
>

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 0 comments |
headers
Miek Gieben | 11 Nov 2004 15:06

Re: Comments on key rollover req. draft

[On 09 Nov,  <at>  21:51, Samuel wrote in "[dnsop] Comments on key rollov ..."]
> This document has a number of unjustified and mutually exclusive
> requirements.  To wit:

in the dnssec-operational draft, we have the following:

3.3.4  Automated Key Rollovers

   As keys must be renewed periodically, there are some motivation to
   automate the rollover process (also see [12])

   o  ZSK rollovers are easy to automate as only the local zone is
      involved.
   o  A KSK rollover needs interaction between the parent and child.
      Data exchange is needed to provide the new keys to the parent,
      consequently, this data must be authenticated and integrity must
      be guaranteed in order to avoid attacks on the rollover.
   o  All time and TTL considerations presented in Section 3.3 apply to
      an automated rollover.

which in my mind sums it all up, so I would favor dropping the key req.
draft,

grtz Miek
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
(Continue reading)

Permalink | Reply | 8 comments |
headers
Ben Laurie | 11 Nov 2004 17:14
Picon

Re: Comments on key rollover req. draft

Miek Gieben wrote:
> [On 09 Nov,  <at>  21:51, Samuel wrote in "[dnsop] Comments on key rollov ..."]
> 
>>This document has a number of unjustified and mutually exclusive
>>requirements.  To wit:
> 
> 
> in the dnssec-operational draft, we have the following:
> 
> 3.3.4  Automated Key Rollovers
> 
>    As keys must be renewed periodically, there are some motivation to
>    automate the rollover process (also see [12])
> 
>    o  ZSK rollovers are easy to automate as only the local zone is
>       involved.
>    o  A KSK rollover needs interaction between the parent and child.
>       Data exchange is needed to provide the new keys to the parent,
>       consequently, this data must be authenticated and integrity must
>       be guaranteed in order to avoid attacks on the rollover.
>    o  All time and TTL considerations presented in Section 3.3 apply to
>       an automated rollover.
> 
> which in my mind sums it all up, so I would favor dropping the key req.
> draft,

This doesn't say anything about SEP keys, though.

Cheers,
(Continue reading)

Permalink | Reply | 7 comments |
headers
Miek Gieben | 11 Nov 2004 17:24

Re: Comments on key rollover req. draft

[On 11 Nov,  <at>  17:14, Ben wrote in "Re: [dnsop] Comments on key ro ..."]
> >   o  ZSK rollovers are easy to automate as only the local zone is
> >      involved.
> >   o  A KSK rollover needs interaction between the parent and child.
> >      Data exchange is needed to provide the new keys to the parent,
> >      consequently, this data must be authenticated and integrity must
> >      be guaranteed in order to avoid attacks on the rollover.
> >   o  All time and TTL considerations presented in Section 3.3 apply to
> >      an automated rollover.
> >
> >which in my mind sums it all up, so I would favor dropping the key req.
> >draft,
> 
> This doesn't say anything about SEP keys, though.

it talks about ksk keys, which are implied to be sep keys (that is
defined somewhere else in the doc)

grtz Miek
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 6 comments |

Gmane