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
>
>