[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 >> >> >
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]