I want to re-iterate some comments in slack
because I think this thread is mixing up two different things, and they
are even all mixed up in the Github issue tracker:
(a)
How to advertise what version of a CSD you support in a product, in your
literature or whatever.
(b)
How to say as a TAXII client what version(s) of CSD you support when you
make a request to a TAXII server.
These are two completely different problem
spaces, and I get the impression everyone is worrying about (b) when it
is not even a problem. I get this impression because everyone keeps talking
about "code" and "coders" and substrings and whatnot.
(b) is not a problem because HTTP already
allows you to do this:
Accept:
application/stix+json; version=2.1, application/stix+json; version=2.1CSD02
.. and the client will handle whichever
it is given (and it will know what it is given via the response header).
No need for substrings or code changes.
Note that no where in STIX or TAXII
is there an "advertisement" of what versions you support. This
is important. Clients ask for what they can consume, not the other
way around.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
"Things may come to those who wait, but only the things left by those
who hustle." - Unknown
From:
Allan Thomson <>
To:
Chris Larsen <>,
Mark Davidson <>, Bret Jordan <>,
"" <>
Date:
03/01/2018 02:39 PM
Subject:
Re: [cti] Advertising
a CSD version of STIX and TAXII
Sent by:
<>
Agreed. To my point that it comes down
to what the org cares about.
Allan
From: Chris Larsen <>
Date: Thursday, March 1, 2018 at 10:35 AM
To: Allan Thomson <>, Mark Davidson
<>, Bret Jordan <>,
"" <>
Subject: Re: [cti] Advertising a CSD version of STIX and TAXII
You still have to decide what
to have your regex look for: exact or simply containing.
Chris Larsen
Architect, WebPulse Threat Research Lab
Symantec
From: Allan Thomson <>
Sent: Thursday, March 1, 2018 11:28:32 AM
To: Chris Larsen; Mark Davidson; Bret Jordan;
Subject: Re: [cti] Advertising a CSD version of STIX and TAXII
Chris – using regex solves item 1 and
should be done anyway to avoid whitespace problems in version numbers.
Allan Thomson,
CTO, Lookingglass
Cyber Solutions
This electronic message transmission
contains information from LookingGlass Cyber Solutions, Inc. which may
be attorney-client privileged, proprietary and/or confidential. The information
in this message is intended only for use by the individual(s) to whom it
is addressed. If you believe that you have received this message
in error, please contact the sender, delete this message, and be aware
that any review, use, disclosure, copying or distribution of the contents
contained within is strictly prohibited
From: Chris Larsen <>
Date: Thursday, March 1, 2018 at 10:15 AM
To: Allan Thomson <>, Mark Davidson
<>, Bret Jordan <>,
"" <>
Subject: Re: [cti] Advertising a CSD version of STIX and TAXII
Speaking as a coder, there
are tigers down both paths:
- If I look for "2.1" (or whatever string) as
an exact/specific match, I end up rejecting the suffixed strings, even
if I probably could have handled their version.
- If I look for a match that simply *contains* the "2.1",
then I accept any of the variants, but then risk having something break
internally when the non-compatible bit that I'm not expecting hits my parser.
...
So I end up coding to (my interpretation of) whatever version
I'm on, and gracefully rejecting whatever bits of input don't match up
with my expectation... (This is what robust input-handling code always
tries to do. So it may not matter much.)
That said, I do like the suffix idea, since it has the
promise of alerting the input engine very early in the process that there
may be incompatibilities (because I don't get the exact match for the "2.1"
string), but that I can expect most of the content to work (since I did
get a "contains" match).
This is why I've always been a bit jealous of the electronics
guys getting to use the word "hardware", because -- darn it!
-- software is hard.
--Chris
Chris Larsen
Architect, WebPulse Threat Research Lab
Symantec
From: <>
on behalf of Allan Thomson <>
Sent: Thursday, March 1, 2018 10:37:42 AM
To: Mark Davidson; Bret Jordan;
Subject: Re: [cti] Advertising a CSD version of STIX and TAXII
Mark – I generally agree with your points.
However, when issues occur in interoperability
having the version of 2.1-CSD01 vs 2.1-CSD02 shared between systems will
help debug/issues to be resolved.
I don’t see including the longer version
information hurts your goals/statements but helps interop/debug.
Regards
Allan
From: Mark Davidson <>
Date: Thursday, March 1, 2018 at 9:30 AM
To: Allan Thomson <>, Bret Jordan
<>, ""
<>
Subject: Re: [cti] Advertising a CSD version of STIX and TAXII
I’m in
favor of option #1, as indicated by my comments on the issue, which I’ll
reiterate here:
I'm personally in favor of using the plain
version string, e.g., version=2.1 for all CSDs, for the following reasons:
1. I don't understand
why the stated problem is important to solve - no supporting evidence has
been given in this thread, just a problem statement and various proposed
solutions.
2. Each new CSD and
CS will require code changes to content negotiation, which increases the
chances of interoperability breaking. If the change had supporting arguments,
then I might view this tradeoff as worthwhile.
3. I don't think the
community in general will support multiple CSDs at once, I see the community
supporting the latest CSD/CS. For instance, I don't see testing multiple
CSDs at a plugfest - I see us doing interop testing for just the most recent
CSD or CS.
I guess my biggest concern is - whyis this a problem worth solving? I can see drawbacks for the various solutions
proposed, though I'm not able to reason whether or not there are benefits
to them.
In terms of what I'd bring to a plugfest
or use as a baseline for a vendor integration, I'd only bring something
that implements the most recent CSD or CS, and I would not care one bit
about compatibility with older CSDs.
I want TAXII 2.1 compatibility issues
to arise when two vendors implement different CSDs/CSs, because that's
how we'll move the fastest toward interoperable TAXII 2.1 implementations
in the marketplace.
Thank you.
-Mark
From: <>
on behalf of Allan Thomson <>
Date: Thursday, March 1, 2018 at 12:13 PM
To: Bret Jordan <>, ""
<>
Subject: Re: [cti] Advertising a CSD version of STIX and TAXII
I suggest Option 2) is preferred.
For orgs that don’t care about the sub-version
information they can parse the version string for the <major>.<minor>
information and ignore the rest.
For orgs that care they can use the full
version information.
Allan
From: ""
<> on behalf of Bret Jordan <>
Date: Thursday, March 1, 2018 at 9:06 AM
To: "" <>
Subject: [cti] Advertising a CSD version of STIX and TAXII
All,
We have been having a discussion on Slack (#taxii) and
in the TAXII Github issue tracker for issue 49 (https://github.com/oasis-tcs/cti-taxii2/issues/49)
about how to handle, or if we should handle, the ability to advertise a
CSD / draft version that is supported by a solution. As we have not
been able to come to consensus, I am asking the broader community for comments
and feedback.
Problem:
As we begin to release CSDs for STIX and TAXII 2.1 and
the amount of time between releases grows, I believe it will be important
for systems to know and understand which version, even a draft version,
that the solution currently supports to make sure it can work seamlessly.
Options:
1) Do nothing. Always advertise "2.1". So
for CSD01, CSD02, CSD03, etc, you would always just advertise "2.1".
The risks to this that I see are, clients will have no
way of knowing if their product is talking to another product that supports
that same version of features. If everything was always additive, this
"might" be okay. However, given our new process and how concepts
can be dropped before the final CS, if they do not have support or code,
then a client with support for CSD02 might not work with a client that
supports CSD03. And there would be no way for the clients to know that,
without two humans talking it through.
Also we may have a situations where something is added
to CSD01 and then radically changed in CSD02 due to issues that are found
during development. If this happens, a server that is hosting content and
is able to update more quickly, will have no way of telling a client (that
has not yet updated) that it is using the newer version.
2) Add some sort of designation or suffix to the end of
the version that represents an ever increasing value that can easily distinguish
the version you are using. Say for CSD01 through CSD03 you
could do 2.1-draft01, 2.1-draft02, 2.1-draft03, and then when the final
version is ready for a CS level release, the suffix would be dropped and
the version would be just 2.1.
Thoughts?
Bret
Disclaimer: This message is intended only
for the use of the individual or entity to which it is addressed and may
contain information which is privileged, confidential, proprietary, or
exempt from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the intended
recipient, you are strictly prohibited from disclosing, distributing, copying,
or in any way using this message. If you have received this communication
in error, please notify the sender and destroy and delete any copies you
may have received.
