Re: [DNSOP] Value of 4641bis
Thierry Moreau <thierry.moreau@connotech.com> Sun, 24 January 2010 17:16 UTC
Return-Path: <thierry.moreau@connotech.com>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424FA3A690B for <dnsop@core3.amsl.com>; Sun, 24 Jan 2010 09:16:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwmWO0bl8UxB for <dnsop@core3.amsl.com>; Sun, 24 Jan 2010 09:16:26 -0800 (PST)
Received: from smtp121.rog.mail.re2.yahoo.com (smtp121.rog.mail.re2.yahoo.com [206.190.53.26]) by core3.amsl.com (Postfix) with SMTP id 360943A681E for <dnsop@ietf.org>; Sun, 24 Jan 2010 09:16:25 -0800 (PST)
Received: (qmail 18561 invoked from network); 24 Jan 2010 17:16:25 -0000
Received: from 209-148-182-228.dynamic.rogerstelecom.net (thierry.moreau@209.148.182.228 with plain) by smtp121.rog.mail.re2.yahoo.com with SMTP; 24 Jan 2010 09:16:25 -0800 PST
X-Yahoo-SMTP: 7IPMVjmswBCDdW1xQhDBl8GZu.GNdc4Rou3wNA--
X-YMail-OSG: BWM8ID0VM1lMKKbamxioK_tR3z8Kv1NF_JFS90GW983M0z6LwhXzF2QJUDJikmnjKQ--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4B5C82E2.5020606@connotech.com>
Date: Sun, 24 Jan 2010 12:26:58 -0500
From: Thierry Moreau <thierry.moreau@connotech.com>
User-Agent: Thunderbird 2.0.0.17 (X11/20090608)
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <a06240810c77e721d038d@10.31.200.228> <06A861D0-FBF4-4E71-8DCC-31C971AA0326@virtualized.org> <d3aa5d01001211326s15ecb953tcef30444f07b03d4@mail.gmail.com> <a06240800c77e784bf4ec@[10.31.200.228]> <B02DAB14-03E2-49EF-ABDD-C0542F0FC04F@dnss.ec> <645C47F3-91A7-4874-B0DD-402F1A7AE307@rfc1035.com> <BDB79242-227E-41C9-AF10-674948A552D4@dnss.ec> <503DA9EF-A56F-4069-8C79-ED09F30FFD69@rfc1035.com> <20100122124539.GB84189@shinkuro.com> <20100122152302.GA22286@vacation.karoshi.com.> <20100123001706.GB85026@shinkuro.com> <F3F90A9A-440E-462E-8E74-CDF5C35452E6@virtualized.org> <p06240889c780e33872cf@[10.20.30.158]>
In-Reply-To: <p06240889c780e33872cf@[10.20.30.158]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: dnsop@ietf.org, David Conrad <drc@virtualized.org>
Subject: Re: [DNSOP] Value of 4641bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jan 2010 17:16:27 -0000
Paul Hoffman wrote: > At 6:07 PM -0800 1/22/10, David Conrad wrote: > >> Operationally, people will do what they think is appropriate regardless of what is written in an RFC. In some version of an ideal world, folks who care about "doing the right thing" could point to an RFC and ask vendors if they implement that RFC (pre >> > suming the RFC describes doing the right thing). I don't fully get why it makes sense to dumb down RFCs in this context, but I'm sure it's because I'm missing something. > > You are. People will tell operators "an RFC exists that covers your operation, so you must follow it". We see that all the time in the IETF in general, and I believe at least one person said it at the mic at the DNSOP WG in Dublin. > > Thus, we really want our operational RFCs to reflect the widest range of best practices that are actually considered "best". If we get lazy and just list one scenario, we will be hurting the Internet by restricting some organizations to following one mo > del when another might have made more sense for them. > Then, you perpetuate the IT security paradigm where the operator complies to an auditable specifications-based operations guide, but the attackers are given opportunities to pass through the cracks. That's because a given (operational) instance applies a single scenario that is unique and never fully examined: the RFC approach with multiple scenarios fails to provide a full analysis opportunity for any single one (that would be obviously out of scope in some aspects). For instance, full review of an operational plan requires disclosure of internal security measures (around personnel turnover) that are not typically subject to formalization in a form suitable for IT security analysis. I don't have an answer for this paradox. Regards, - Thierry Moreau > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > >
- [DNSOP] rfc4641bis: ZSK-roll-frequency Olaf Kolkman
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Eric Rescorla
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Rose, Scott W.
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Olaf Kolkman
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Edward Lewis
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Andrew Sullivan
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Edward Lewis
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Andrew Sullivan
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Edward Lewis
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Rose, Scott W.
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Andrew Sullivan
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Tony Finch
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Andrew Sullivan
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Paul Hoffman
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Andrew Sullivan
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Paul Wouters
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Edward Lewis
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Eric Rescorla
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Edward Lewis
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Paul Hoffman
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Olaf Kolkman
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Edward Lewis
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Eric Rescorla
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Masataka Ohta
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Masataka Ohta
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Andrew Sullivan
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Andrew Sullivan
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Paul Hoffman
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Masataka Ohta
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Edward Lewis
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency David Conrad
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Eric Rescorla
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Andrew Sullivan
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Edward Lewis
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Edward Lewis
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Todd Glassey
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency David Conrad
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Paul Hoffman
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency David Conrad
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Roy Arends
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Andrew Sullivan
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Paul Wouters
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Roy Arends
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Eric Rescorla
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Todd Glassey
- [DNSOP] key rollover for real Jim Reid
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Paul Wouters
- Re: [DNSOP] key rollover for real Roy Arends
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Eric Rescorla
- Re: [DNSOP] key rollover for real Jim Reid
- Re: [DNSOP] key rollover for real Roy Arends
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Paul Wouters
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Eric Rescorla
- Re: [DNSOP] key rollover for real Andrew Sullivan
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Todd Glassey
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Tony Finch
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Paul Hoffman
- Re: [DNSOP] key rollover for real Joe Abley
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency bmanning
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Edward Lewis
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Alex Bligh
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Todd Glassey
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Paul Hoffman
- Re: [DNSOP] key rollover for real Andrew Sullivan
- Re: [DNSOP] key rollover for real David Conrad
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Eric Rescorla
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Niall O'Reilly
- [DNSOP] Value of 4641bis Paul Hoffman
- Re: [DNSOP] Value of 4641bis Thierry Moreau
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Edward Lewis
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Paul Wouters
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Francis Dupont
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Paul Hoffman
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Rose, Scott W.
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Paul Hoffman
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Masataka Ohta
- Re: [DNSOP] rfc4641bis: ZSK-roll-frequency Francis Dupont