OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-taxii message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-taxii] Protocol Shortlist - Add HTTP


I can go with HTTP/2 and that might even solve more of our problems and help us look slightly more progressive without the scary factor.  So as of right now we have two options for a protocol...

HTTP/1.1
HTTP/2


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Aug 25, 2015, at 12:21, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

I think HTTP/2.0 should be on the short list as well, as it also meets all the requirements, and enables various additional capabilities.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


<graycol.gif>"Davidson II, Mark S" ---2015/08/25 02:57:00 PM---All, As I mentioned in a previous email, not having a protocol to work with has ended up slowing dow

From: "Davidson II, Mark S" <mdavidson@mitre.org>
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/08/25 02:57 PM
Subject: [cti-taxii] Protocol Shortlist - Add HTTP
Sent by: <cti-taxii@lists.oasis-open.org>





All,

As I mentioned in a previous email, not having a protocol to work with has ended up slowing down prototype work. IMO, a shortlist of protocols needs to be picked for prototyping efforts, and I’d like to start that by proposing HTTP be added to the shortlist. That will unblock me so I can write some code that does something. I think HTTP meets our requirements and also works well with Sergey’s idea of incremental change.

Here’s my take on how HTTP stacks up to the protocol requirements we’ve written down so far [1]:

> 1. Minimal changes to existing firewall deployments
AFAIK, just about every FW everywhere let’s HTTP and HTTPS through, so I think this one is met.

> 2. Robust ecosystem of TAXII Server platforms
There are lots of platforms (Web Servers, Messaging Products, etc) that support HTTP or have HTTP interfaces. I’d go as far as to say that I don’t think choosing HTTP would preclude any technology stack that I’ve been exposed to.

> 3. Ubiquitous, well supported client libraries.
HTTP has libraries in every language on just about every platform that I know about.

> 4. Well understood by the software development community
HTTP is IMO the best understood protocol by the development community.

> 5. Supportable in cloud infrastructures
HTTP is used widely in cloud infrastructures

> 6. Integration within existing vendor communication channels
I can’t really speak to this one – somebody else will have to chime in.

> 7. Ability to push information from a server to a client
This is where native HTTP doesn’t work great. Though perhaps a workaround like long polling could be sufficient.

> 8. Protocol efficiency / minimal verbosity
I don’t have any experience or information to make an assessment here.

Please note that this does not represent a group consensus, merely that HTTP is being explored further. Absent dissenting opinions, I’ll work on an HTTP-based prototype and share something about it before too long.

Are there other protocols that should be added to the shortlist?

Thank you.
-Mark

[1] https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-2.0-Requirements#protocol-requirements


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]