[TAXII] JSON Message Binding Spec v0.4 - complete rewrite of section 3

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[TAXII] JSON Message Binding Spec v0.4 - complete rewrite of section 3

Jordan, Bret
I have completely rewritten section 3 from 3.1-3.7 to address all the feedback given and to get rid of most of the arrays of objects and to GREATLY simplify and take advantage of the JSON structure.  This structure should be more to everyone’s liking and simplify and speed up the serialization.  Please review and give me feedback.

 




Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 


TAXII_JSON_Message_Binding_Specification v0.4.pdf (282K) Download Attachment
signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] JSON Message Binding Spec v0.4 - complete rewrite of section 3

mdavidson

Bret,

 

# First, a few technical comments on this round:

 

- Section 3 adds a requirement for Message IDs that goes beyond what the TAXII Services spec requires, hindering interoperability between message bindings. I recommend removing this requirement. I see what you have suggested as a proposal for Message IDs in a future revision of TAXII

- In the tables, you use terms like “string”, “object”, and “array”. These terms are not defined in the document. For instance, the XML binding, at the beginning of section 3, discusses XML elements vs XML attributes. I recommend at least mentioning these (or referencing where they can be found).

- In your CollectionInformationResponse, your URLs are only URL paths. I’m probably partly to blame for this, because right now that’s what YETI does by default (we’re fixing that!). These should be full URLs. I’d suggest using example.com as your domain.

- In your bibliography, you reference the TAXII Services Spec 1.0. I’m guessing you meant to reference the 1.1 spec?

 

# A quick response to some previous points:

TAXII absolutely allows the specification of multiple Message and Protocol Bindings – additional bindings were explicitly designed for. That said, it’s my personal opinion that all formal additions of bindings should be carefully considered.

 

# Next, a slight tangent. I ask these questions to gain a better understanding of the TAXII community. (I’m asking Bret, but if anyone has experience that could help answer these questions, I think the community would be better off for having heard it),

 

You mentioned that you’ve had a lot of feedback/discussions regarding TAXII. Can you share (at a high level) any comments/praise/criticism of TAXII in terms of the use cases it covers, how easy/hard it is to use TAXII to share threat information? What I mean is, at a level above specific implementations of ideas, has there been comment on the actual ideas themselves? Are there use cases that are not covered? Use cases that could be more straightforward?

 

Also, if this is possible, could you categorize the people that have been requesting JSON (e.g., DevOps network defenders, Product Development Teams)? Are there other requests you’ve heard?

 

Thank you.

-Mark

 

From: Jordan, Bret [mailto:[hidden email]]
Sent: Wednesday, March 25, 2015 1:36 AM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: [TAXII] JSON Message Binding Spec v0.4 - complete rewrite of section 3

 

I have completely rewritten section 3 from 3.1-3.7 to address all the feedback given and to get rid of most of the arrays of objects and to GREATLY simplify and take advantage of the JSON structure.  This structure should be more to everyone’s liking and simplify and speed up the serialization.  Please review and give me feedback.

 

 

Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] JSON Message Binding Spec v0.4 - complete rewrite of section 3

Terry MacDonald
Hi Mark,

I know that I would like to see an improvement on size. Anything that packs together more data into the same space is good for me. I would ultimately like to see a binary representation so that we can send large quantities of data efficiently from consolidated endpoints, as I believe we will be seeing a few centralized TAXII-based threat intel exchanges in general use. Those centralized threat exchanges will need to send a large amount of data, and being able to compact that as much as possible will be extremely important.

I see this JSON implementation as a first step in that direction. JSON is not as 'scary' as XML, and is what a lot of web developers are familiar with. I do believe that a JSON representation of STIX (and TAXII to support it) will give people an option to use a format they find more accessible. 

I am less concerned about fragmentation, as long as we make sure that the libraries are pluggable in nature. We should be able to plug in the python-stix library, and a python-stix-json library, and have libtaxii automatically use the relevant library based on what the developer wants to use (or what the other end supports). I would hope that auto-negotiation functionality is taken care of in the future, in much the same way as it is in TLS version negotiation with browsers and servers.

Cheers
Terry MacDonald


On 25 March 2015 at 22:43, Davidson II, Mark S <[hidden email]> wrote:

Bret,

 

# First, a few technical comments on this round:

 

- Section 3 adds a requirement for Message IDs that goes beyond what the TAXII Services spec requires, hindering interoperability between message bindings. I recommend removing this requirement. I see what you have suggested as a proposal for Message IDs in a future revision of TAXII

- In the tables, you use terms like “string”, “object”, and “array”. These terms are not defined in the document. For instance, the XML binding, at the beginning of section 3, discusses XML elements vs XML attributes. I recommend at least mentioning these (or referencing where they can be found).

- In your CollectionInformationResponse, your URLs are only URL paths. I’m probably partly to blame for this, because right now that’s what YETI does by default (we’re fixing that!). These should be full URLs. I’d suggest using example.com as your domain.

- In your bibliography, you reference the TAXII Services Spec 1.0. I’m guessing you meant to reference the 1.1 spec?

 

# A quick response to some previous points:

TAXII absolutely allows the specification of multiple Message and Protocol Bindings – additional bindings were explicitly designed for. That said, it’s my personal opinion that all formal additions of bindings should be carefully considered.

 

# Next, a slight tangent. I ask these questions to gain a better understanding of the TAXII community. (I’m asking Bret, but if anyone has experience that could help answer these questions, I think the community would be better off for having heard it),

 

You mentioned that you’ve had a lot of feedback/discussions regarding TAXII. Can you share (at a high level) any comments/praise/criticism of TAXII in terms of the use cases it covers, how easy/hard it is to use TAXII to share threat information? What I mean is, at a level above specific implementations of ideas, has there been comment on the actual ideas themselves? Are there use cases that are not covered? Use cases that could be more straightforward?

 

Also, if this is possible, could you categorize the people that have been requesting JSON (e.g., DevOps network defenders, Product Development Teams)? Are there other requests you’ve heard?

 

Thank you.

-Mark

 

From: Jordan, Bret [mailto:[hidden email]]
Sent: Wednesday, March 25, 2015 1:36 AM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: [TAXII] JSON Message Binding Spec v0.4 - complete rewrite of section 3

 

I have completely rewritten section 3 from 3.1-3.7 to address all the feedback given and to get rid of most of the arrays of objects and to GREATLY simplify and take advantage of the JSON structure.  This structure should be more to everyone’s liking and simplify and speed up the serialization.  Please review and give me feedback.

 

 


Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] JSON Message Binding Spec v0.4 - complete rewrite of section 3

Jason Keirstead
In reply to this post by mdavidson

FWIW, in regards to you rlast point (feedback)

Now that we're getting into the nitty gritty of implementing TAXII, one thing that I feel is missing form the spec is a notion of poll interval. That is, TAXII defines a POLL, but it gives no ability for the TAXII provider to suggest a POLL interval, nor any way for the consumer to guess as to what is an appropriate interval.

As a result, I am fearful of people polling every 10 seconds and bringing down servers who can't deal with the requests.

I think it would be nice if part of the Taxii Collection Information Response included an optional polling-interval field that a provider could pass to the client telling it how often it can poll that collection. I also think a Status Type should be added called "Polling Too Frequently" (or some better name) that a service can optionally respond with if clients are violating the polling interval.

-
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


Inactive hide details for "Davidson II, Mark S" ---2015/03/25 08:46:00 AM---Bret, # First, a few technical comments on this rou"Davidson II, Mark S" ---2015/03/25 08:46:00 AM---Bret, # First, a few technical comments on this round:

From: "Davidson II, Mark S" <[hidden email]>
To: <[hidden email]>
Date: 2015/03/25 08:46 AM
Subject: Re: [TAXII] JSON Message Binding Spec v0.4 - complete rewrite of section 3





Bret,
 
# First, a few technical comments on this round:
 
- Section 3 adds a requirement for Message IDs that goes beyond what the TAXII Services spec requires, hindering interoperability between message bindings. I recommend removing this requirement. I see what you have suggested as a proposal for Message IDs in a future revision of TAXII
- In the tables, you use terms like “string”, “object”, and “array”. These terms are not defined in the document. For instance, the XML binding, at the beginning of section 3, discusses XML elements vs XML attributes. I recommend at least mentioning these (or referencing where they can be found).
- In your CollectionInformationResponse, your URLs are only URL paths. I’m probably partly to blame for this, because right now that’s what YETI does by default (we’re fixing that!). These should be full URLs. I’d suggest using example.com as your domain.
- In your bibliography, you reference the TAXII Services Spec 1.0. I’m guessing you meant to reference the 1.1 spec?
 
# A quick response to some previous points:
TAXII absolutely allows the specification of multiple Message and Protocol Bindings – additional bindings were explicitly designed for. That said, it’s my personal opinion that all formal additions of bindings should be carefully considered.
 
# Next, a slight tangent. I ask these questions to gain a better understanding of the TAXII community. (I’m asking Bret, but if anyone has experience that could help answer these questions, I think the community would be better off for having heard it),
 
You mentioned that you’ve had a lot of feedback/discussions regarding TAXII. Can you share (at a high level) any comments/praise/criticism of TAXII in terms of the use cases it covers, how easy/hard it is to use TAXII to share threat information? What I mean is, at a level above specific implementations of ideas, has there been comment on the actual ideas themselves? Are there use cases that are not covered? Use cases that could be more straightforward?
 
Also, if this is possible, could you categorize the people that have been requesting JSON (e.g., DevOps network defenders, Product Development Teams)? Are there other requests you’ve heard?
 
Thank you.
-Mark
 
    From: Jordan, Bret [[hidden email]]
    Sent:
     Wednesday, March 25, 2015 1:36 AM
    To:
     taxii-discussion-list Trusted Automated Exchange of Indicator In
    Subject:
     [TAXII] JSON Message Binding Spec v0.4 - complete rewrite of section 3
     
    I have completely rewritten section 3 from 3.1-3.7 to address all the feedback given and to get rid of most of the arrays of objects and to GREATLY simplify and take advantage of the JSON structure.  This structure should be more to everyone’s liking and simplify and speed up the serialization.  Please review and give me feedback.
     
     

Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] JSON Message Binding Spec v0.4 - complete rewrite of section 3

mdavidson

Jason,

 

I’ve submitted a GitHub issue for the polling interval concept [1], and added your comment to an existing issue for rate limiting [2]. I think both of these are good suggestions.

 

Thank you.

-Mark

 

[1] https://github.com/TAXIIProject/TAXII-Specifications/issues/64

[2] https://github.com/TAXIIProject/TAXII-Specifications/issues/17

 

From: Jason Keirstead [mailto:[hidden email]]
Sent: Thursday, March 26, 2015 3:27 PM
To: Davidson II, Mark S
Cc: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: Re: [TAXII] JSON Message Binding Spec v0.4 - complete rewrite of section 3

 

FWIW, in regards to you rlast point (feedback)

Now that we're getting into the nitty gritty of implementing TAXII, one thing that I feel is missing form the spec is a notion of poll interval. That is, TAXII defines a POLL, but it gives no ability for the TAXII provider to suggest a POLL interval, nor any way for the consumer to guess as to what is an appropriate interval.

As a result, I am fearful of people polling every 10 seconds and bringing down servers who can't deal with the requests.

I think it would be nice if part of the Taxii Collection Information Response included an optional polling-interval field that a provider could pass to the client telling it how often it can poll that collection. I also think a Status Type should be added called "Polling Too Frequently" (or some better name) that a service can optionally respond with if clients are violating the polling interval.

-
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


Inactive hide details for "Davidson II, Mark S" ---2015/03/25 08:46:00 AM---Bret, # First, a few technical comments on this rou"Davidson II, Mark S" ---2015/03/25 08:46:00 AM---Bret, # First, a few technical comments on this round:

From: "Davidson II, Mark S" <[hidden email]>
To: <[hidden email]>
Date: 2015/03/25 08:46 AM
Subject: Re: [TAXII] JSON Message Binding Spec v0.4 - complete rewrite of section 3





Bret,
 
# First, a few technical comments on this round:
 
- Section 3 adds a requirement for Message IDs that goes beyond what the TAXII Services spec requires, hindering interoperability between message bindings. I recommend removing this requirement. I see what you have suggested as a proposal for Message IDs in a future revision of TAXII
- In the tables, you use terms like “string”, “object”, and “array”. These terms are not defined in the document. For instance, the XML binding, at the beginning of section 3, discusses XML elements vs XML attributes. I recommend at least mentioning these (or referencing where they can be found).
- In your CollectionInformationResponse, your URLs are only URL paths. I’m probably partly to blame for this, because right now that’s what YETI does by default (we’re fixing that!). These should be full URLs. I’d suggest using example.com as your domain.
- In your bibliography, you reference the TAXII Services Spec 1.0. I’m guessing you meant to reference the 1.1 spec?
 
# A quick response to some previous points:
TAXII absolutely allows the specification of multiple Message and Protocol Bindings – additional bindings were explicitly designed for. That said, it’s my personal opinion that all formal additions of bindings should be carefully considered.
 
# Next, a slight tangent. I ask these questions to gain a better understanding of the TAXII community. (I’m asking Bret, but if anyone has experience that could help answer these questions, I think the community would be better off for having heard it),
 
You mentioned that you’ve had a lot of feedback/discussions regarding TAXII. Can you share (at a high level) any comments/praise/criticism of TAXII in terms of the use cases it covers, how easy/hard it is to use TAXII to share threat information? What I mean is, at a level above specific implementations of ideas, has there been comment on the actual ideas themselves? Are there use cases that are not covered? Use cases that could be more straightforward?
 
Also, if this is possible, could you categorize the people that have been requesting JSON (e.g., DevOps network defenders, Product Development Teams)? Are there other requests you’ve heard?
 
Thank you.
-Mark
 

From: Jordan, Bret [[hidden email]]
Sent:
 Wednesday, March 25, 2015 1:36 AM
To:
 taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject:
 [TAXII] JSON Message Binding Spec v0.4 - complete rewrite of section 3

 
I have completely rewritten section 3 from 3.1-3.7 to address all the feedback given and to get rid of most of the arrays of objects and to GREATLY simplify and take advantage of the JSON structure.  This structure should be more to everyone’s liking and simplify and speed up the serialization.  Please review and give me feedback.