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] TAXII Protocol Shortlist


AMQP and potentially MQTT if you want to consider your vision of TAXII Clients on IoT.

Sent from Outlook




On Thu, Aug 27, 2015 at 5:57 AM -0700, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:

We have three protocols on the short list...  

HTTP/1.1
HTTP/2
ZMTP

Are there any others we should be actually thinking about or discussing?   If so please suggest them.  I would also like to start hearing pros and cons, discussion / debate about which one to use in the end.  Once we come to a steady state on discussion, we can then proceed to a vote.  Lets take the next few weeks to discuss this.. I really want to hear your opinions.  We will also plan to also discuss this on our next community call, as we stated a few days ago. 

We can not really move further on the future of TAXII, as lot of future decisions will be impacted by this one, until this initial decision gets made so lets discuss it and make a decision. 

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 27, 2015, at 06:36, Davidson II, Mark S <mdavidson@MITRE.ORG> wrote:

Sergey,

Is this the spec for zmtp: http://rfc.zeromq.org/spec:37 ?

-Mark

-----Original Message-----
From: Sergey Polzunov [mailto:sergey@intelworks.com]
Sent: Thursday, August 27, 2015 8:32 AM
To: Jordan, Bret <bret.jordan@BLUECOAT.COM>
Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Davidson II, Mark S <mdavidson@mitre.org>; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Protocol Shortlist - Add HTTP

Hey Bret,

I suggest adding ZMTP (http://zmtp.org/) to the mix

Thanks,
Sergey Polzunov
Intelworks


On 26 Aug 2015, at 16:40, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:

This sounds like a really interesting idea that we need to explore and build code to test.

Does anyone have any objection to moving forward with the two protocols we are discussing?

HTTP1/1
HTTP/2

Are there any other protocols we should be looking at?  Please either bring them up on the list or come to the next call prepared to discuss them.  We would like to come to general consensus on this decision in the next 2 weeks so we can start discussing and thinking through other much more interesting problems.


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 26, 2015, at 07:01, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

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


<graycol.gif>"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







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