Re: [scap_interest] Questions from David Harrington

Steve Hanna <> Mon, 08 November 2010 11:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AEA3528C134 for <>; Mon, 8 Nov 2010 03:19:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.297
X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ua10BnJUNzdq for <>; Mon, 8 Nov 2010 03:19:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AFACE28C145 for <>; Mon, 8 Nov 2010 03:19:55 -0800 (PST)
Received: by vws3 with SMTP id 3so1797081vws.31 for <>; Mon, 08 Nov 2010 03:20:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=RKKp1wVieqB6lyfrn+5AcK6tIbhT/rK4H5L/AVhQVrU=; b=E0DHouYqQ+yL3j4nhGsOMWkGV7gPsRhX7mS6pxVoOetuQwwh9z0Y4bH7lPA/xb8caY GbyBY4mXt8cdk4f9ym2r/XELo3yB7JwiiS95z1Caxb+jrSGB0at9wDgThRugsu7CdkBI tsAUcn0qsdwC22KOn3JXnZQP3CFp9BN9PkkLg=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=j70Di2rC5Qa4Qc4pEdCjqzrKQ2ThzHxDp+me9GGlnuLujnnCkK77UyNFSe3ZF1fZXs TczV2rgRAkhZd7QB62ODDyk04IbM9/+dX4kk/4GO2s/gc8MzNt/f0Fval68UTisBV1eC J7vUjpXAPP/Ke254MnlTQ8D4tz3Ei0+XVvWZI=
MIME-Version: 1.0
Received: by with SMTP id o4mr4058692qac.337.1289215216482; Mon, 08 Nov 2010 03:20:16 -0800 (PST)
Received: by with HTTP; Mon, 8 Nov 2010 03:20:16 -0800 (PST)
Date: Mon, 8 Nov 2010 19:20:16 +0800
Message-ID: <>
From: Steve Hanna <>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [scap_interest] Questions from David Harrington
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Nov 2010 11:19:56 -0000

I'd like to address one of David's questions:

> 4) In the past, IDS work has not been considered IETF work; IDS
> vendors tend to have their own security-related fora for sharing
> information. NEA has been brought into the IETF from the TSG, and the
> IEEE has created the Industry Connections Security Group that focuses
> on standardizing malware definitions.  I personally would love to have
> that community come into the IETF and use the IETF process for
> **developing** the specifications, not just for approving the
> specifications after they're done. Is the industry seriously
> interested in participating in the IETF, or will they continue to
> create multiple security fora to develop specifications and then bring
> their specifications to the IETF for approval as RFCs?

First, TCG and the SCAP community have not developed IDS standards.
IDS isn't really relevant to this discussion. But I think David's raising a
good issue so I'll just assume that David means security standards.
If that's not what David meant, please let me know. But I think his
point is valid with that substitution so I'll address it in that way.

Second, I'll speak to the case of NEA since I know all about that.
The TCG TNC community HAS come into the IETF and used the
IETF process to develop the NEA specifications, along with lots
of people who are not part of TCG. Yes, we had done some work
before we came to IETF. We brought our specifications to IETF and
offered them as initial drafts, giving change control over to the IETF.
If you compare those initial drafts to the RFCs that came out of the
IETF process, you'll see that lots of valuable changes and substantial
improvements were made to the specifications over the last few years.

David asks if the security community (I assume) will continue to develop
specifications in other fora and then bring those specifications to the IETF.
I certainly hope so! Many of the best and most successful security RFCs
started out in other fora: SSL/TLS, X.509, Kerberos, ssh, etc. David may
not like this approach but it has been demonstrably quite successful in
the security area and, I think, in other areas. Nobody should expect the
IETF process to be a rubber stamp. It's not. But that doesn't mean that
we should reject things that started out elsewhere and now want to come
into the IETF to get broader participation and review. In fact, we should
encourage that! Solutions developed by the IETF from scratch often
turn into endless academic exercises divorced from reality. At least,
I have seen that happen all too often.