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

["Jordan, Bret" <bret.jordan@bluecoat.com>]

I have also spent a lot of time thinking through the various options, and Mark and I have discussed them at length on a daily basis..  Here is my take, kind of where I am leaning, but please push back or disagree.  I would love to hear your thoughts.  

1) The way I see it, it really comes down to a question of doing something over HTTP or something over a messaging protocol, like AMQP, ZeroMQ, etc....  

2) HTTP in my option is probably the best and easiest option for us.  So I would agree to add HTTP to the short list.  

i) Does everyone agree with this?  

ii) Does anyone think we should be looking at something other than HTTP?

3) The biggest draw back to HTTP is the lack of server push.  But I think we can solve that in a very creative way with long-polling that will also be super easy to implement.  

So in regards to a TAXII 2.0 vs TAXII 1.5...  I think the small and important changes we would make will result in a breaking change, thus I think the need for a TAXII 2.0..  However, I do not think we have done a good job thus far marketing our message to the community.  I do not think TAXII 2.0 is as scary and new as it may seem from our discussions...

Think of it this way:

1) Data-Collections + Data-Feeds = Channels 

2) We add a real security and authentication system to TAXII, thus user authentication, groups, and policies on channels.

3) We simplify the messages and the back and forth that exists in TAXII 1.1 to make TAXII 2.0 easier and faster

4) We define TAXII 2.0 to have some base level functionality that every TAXII server MUST have.  This, I believe, will make it easier for people and vendors to use TAXII... They will know what is there. For example, Soltra had to start shipping their solution with default Data-Collections and such already configured, so that people could use it out of the box.  

When we start looking at it like that. Then I think TAXII 2.0 is not so scary and seems a lot more like TAXII 1.1, just better, easier, and faster. 

Please spend some time thinking about the idea of continuing to use HTTP as the transport for TAXII and either give your comments on the list or come to the next call in 2 weeks ready to express your options. I would really like to get this initial decision out of the way sooner rather than later as it is will impact a lot of future decisions.  

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 11:56, Davidson II, Mark S <mdavidson@MITRE.ORG> wrote:

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