RE: [Non-DoD Source] Re: [openc2-imple] RE: OC2 HTTP(no S) Spec

Dave,

I agree with you (if I understand correctly). I think you are suggesting a âbase specâ with annexes that cover https, other security means etc. There is a bit of a nuance though, if we go with that approach, then what you really have is a base HTTP spec, you have two or more annexes that spell out TLS or whatever and you modify the conformance criteria. A bit more tidy than a base HTTPS spec with an annex that deprecates for testing environs and another annex that replaces TLS with whatever.

From: openc2-imple@lists.oasis-open.org <openc2-imple@lists.oasis-open.org> On Behalf Of Dave Lemire
Sent: Wednesday, February 19, 2020 9:27 AM
To: MARONEY, PATRICK <rx118r@att.com>
Cc: duncan sfractal.com <duncan@sfractal.com>; oasis.oc2.icsc <openc2-imple@lists.oasis-open.org>
Subject: [Non-DoD Source] Re: [openc2-imple] RE: OC2 HTTP(no S) Spec

Based on our experience at the plug fest, I'm totally in favor of adding support for HTTP. My initial preference (not yet based on deep thought) would be to address this within the current specification, since I think it has very little to no impact on message content. So it seems to me that we could have

* Security via HTTPS

* HTTP with security via other means

* HTTP without security (testing mode only).

added to the scope of the current spec. This seems less likely to generate confusion, IMO, than having both HTTP and HTTPS specifications. It also means that evolutions of the message format could be handled in one place rather than several.

Dave

David Lemire, CISSP

Systems Engineer

HII Mission Driven Innovative Solutions (HII-MDIS) â formerly G2, Inc.

Technical Solutions Division

302 Sentinel Drive | Annapolis Junction, MD 20701

Email: dave.lemire@g2-inc.com

Work: 301-575-5190 | Mobile: 240-938-9350

On Mon, Feb 17, 2020 at 5:51 PM MARONEY, PATRICK <rx118r@att.com> wrote:

Another valid âsecureâ HTTP is where you have your systems behind an appliance (i.e., an F5 LTM/APM/ASM) that proxies/accelerates SSL and uses HTTP to completely isolated back-end infrastructure. This model greatly improves performance, development, troubleshooting, and monitoring.

Patrick Maroney

Principal âTechnology Security

AT&T Chief Security Office

From: openc2-imple@lists.oasis-open.org <openc2-imple@lists.oasis-open.org> On Behalf Of duncan sfractal.com
Sent: Monday, February 17, 2020 5:18 PM
To: oasis.oc2.icsc <openc2-imple@lists.oasis-open.org>
Subject: [openc2-imple] OC2 HTTP(no S) Spec

At the plugfest, I implemented the HTTP version of the HTTPS spec. I think there are valid uses of HTTP (without the S) for OpenC2. They just need to be caveated with the fact that HTTP doesnât provide security. Note most of the interworking issues at plugfest had nothing to do with OpenC2 and were just plain old HTTPS cert issues. Besides plugfest testing, I can provide valid usecases for HTTP (eg where SPA transport is sufficient for authentication and transmission privacy is not needed â note this may apply to large number of IoT usecases).

I recommend the IC-SC consider creating another transport spec, an âappropriately caveatedâ HTTP spec.

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info/

openc2-imple message