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
From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org]
On Behalf Of Jason Keirstead
Sent: Wednesday, August 26, 2015 8:10 AM
To: Davidson II, Mark S <mdavidson@mitre.org>
Cc: Jordan, Bret <bret.jordan@bluecoat.com>; cti-taxii@lists.oasis-open.org
Subject: RE: [cti-taxii] Protocol Shortlist - Add HTTP
There are a number of facilities available in HTTP/2.0 that could be of great use to TAXII - for example, as you mentioned below, server push. If HTTP/2.0 is part of the specification, then these facilities can be assumed to be present
and we can utilize them in the TAXII specification. If not, then we are stuck with HTTP/1.1 facilities.
The answer to "how much would the application code have to know" also depends. For a protocol like TAXII, it depends very much on how it is written and where it is running. It is not always going to be an option for someone implementing a TAXII service to simply
stick an Apache instance in front, for example if it is for example running on an embedded device.
-
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 08:32:23 AM---Dumb question – what has to change in application code if HTTP/2 is used? Asking the question anothe
From: "Davidson II, Mark S" <mdavidson@mitre.org>
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 2015/08/26 08:32 AM
Subject: RE: [cti-taxii] Protocol Shortlist - Add HTTP
Sent by: <cti-taxii@lists.oasis-open.org>
Dumb question – what has to change in application code if HTTP/2 is used?
Asking the question another way – if I write a Python/Django web app for HTTP/1.1 that runs on Apache, what modifications would I need to make in order to support Apache’s HTTP/2 functionality?
Based on what I’ve read, it sounds like application code will have to change very little, if at all. There is a presumption that due to the similarities between HTTP/1.1 and HTTP/2, thigs like Django
(or the underlying WSGI) won’t need to change their interface very much, and therefore will have minimal impact to application developers.
As I understand it, HTTP/2 adds some new features (Server Push and Stream Prioritization) that will eventually propagate up to the web developer level, and other features (e.g., binary encoding) will
be handled transparently by the underlying webserver.
This was based on a few minutes of internet searching, so please let me know what I got wrong.
If my assumptions are correct, it seems we can for the most part proceed with a general notion of HTTP and then make a value decision about HTTP/1.1 vs HTTP/2 later on.
Thank you.
-Mark
From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]
Sent: Tuesday, August 25, 2015 5:21 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Davidson II, Mark S <mdavidson@mitre.org>;
cti-taxii@lists.oasis-open.org
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