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

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

Yes exactly - IE - Client makes a TAXII query that returns 100 documents. Those documents contain references to indicators that live in other documents, that weren't matched in the query (possibly hundreds of such references). Instead of the TAXII client making hundreds of dereference requests and the associated HTTP overhead (as they would have to with 1.1), the server can push the documents down with a promise request. If for some esoteric use case the client would not actually want to de-reference, they can just disable it in the connection, as per HTTP/2 spec.

-
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


"Davidson II, Mark S" ---2015/08/26 09:45:52 AM---From my perspective, I’d hope that an embedded device can behave like a client and not as a server,

From: "Davidson II, Mark S" <mdavidson@mitre.org>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/08/26 09:45 AM
Subject: RE: [cti-taxii] Protocol Shortlist - Add HTTP

---

From my perspective, I’d hope that an embedded device can behave like a client and not as a server, and still be able to take all of the actions that might matter in regard to TAXII.
 
I took a quick glance at the section on Server Push [1], and there’s a number of requirements that at first glance seem to be counter to what we’d want. As I understand it, the server can send the client a “promised request” (e.g., I expect you will ask for http://example.com/image.png) and the response to that promised request. The rules are:

· Promised requests MUST be cacheable
· MUST be safe (a.k.a “Read Only”)
· MUST NOT include a request body

These are clearly optimized for the “I’m sending you a web page with 15 images and 5 _javascript_/CSS resources that I know you’re going to ask for next, so let me just go ahead and send those to you before you ask for them”. 
 
In thinking how this might work for messaging, you’d almost have to have a URL structure like this:
http://hostname/<group>/<channel>/<message-id>, where a message is a resource living at a particular URL. Then a request to the channel (e.g., GET hostname/<group>/<channel>/) would include a list of pointers to messages, THEN the server could send promised requests and the responses (one for each message). I’m not sure how well that kind of setup would work outside of a browser context.
 
I think whether server push can be made to work for TAXII is ultimately an unknown. There’s also other reasons we might choose to go with HTTP/2 that haven’t been discussed yet. We will be able to prove these out with prototypes one way or another.
 
In short, I agree with all Jason’s points. I took a slight detour down the rabbit hole of HTTP/2 server push, and I’m unclear on whether server push is something that makes sense for TAXII.
 
-Mark
[1] https://httpwg.github.io/specs/rfc7540.html#PushResources