Re: [scap_interest] Questions from David Harrington

[Steve Hanna <[e-mail]>]

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.

Thanks,

Steve