The more I think about this whole proposal,
the more uncomfortable it makes me. If clients and servers are advertising
support based on CSDs it is going to cause nothing but interoperability
problems. I really think we need to look into
adding a new header to TAXII so that people can simply specify the extensions
they support The negotiation would look like this: GET /api1/collections/91a7b528-80eb-42ed-a74d-c6fbd5a26116/manifest/
HTTP/1.1 Host: example.com Accept: application/vnd.oasis.taxii+json; version=2.1 X-TAXII-Accepted-Extensions: x_oasis-open_org:taxii_rfi X-STIX-Accepted-Extensions: x_oasis-open_org:intralist_matching GET Response HTTP/1.1 200 OK Content-Type: application/vnd.oasis.taxii+json; version=2.1 X-STIX-Provided-Extensions: x_oasis-open_org:intralist_matching - 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:
Bret Jordan <
Bret_Jordan@symantec.com> To:
Jason Keirstead <
Jason.Keirstead@ca.ibm.com> Cc:
Allan Thomson <
athomson@lookingglasscyber.com>,
Chris Larsen <
Chris_Larsen@symantec.com>, "cti@lists.oasis-open.org"
<
cti@lists.oasis-open.org>, Mark Davidson <
Mark.Davidson@nc4.com> Date:
03/01/2018 04:19 PM Subject:
Re: [cti] Re:
[EXT] Re: [cti] Advertising a CSD version of STIX and TAXII Sent by:
<
cti@lists.oasis-open.org> Yes. We just need to define it. And
Terry put forth a proposal last night, and I am okay with his proposal
and several others are as well. We do not yet have consensus, since
the numbers are still too small (given the couple that are against it),
but the growing trend is that people are okay with it. Can we get others to comment on this? There
are very few things left that we need to discuss before we can do our first
TAXII 2.1 CSD01 and this is one of them. Bret From: Jason Keirstead <
Jason.Keirstead@ca.ibm.com> Sent: Thursday, March 1, 2018 1:10:51 PM To: Bret Jordan Cc: Allan Thomson; Chris Larsen;
cti@lists.oasis-open.org; Mark Davidson Subject: Re: [cti] Re: [EXT] Re: [cti] Advertising a CSD version of
STIX and TAXII OK - as long as that is all we are talking
about. When people talk about code and substrings I get lost. - 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: Bret
Jordan <
Bret_Jordan@symantec.com> To: Jason
Keirstead <
Jason.Keirstead@ca.ibm.com> Cc: Allan
Thomson <
athomson@lookingglasscyber.com>, Chris Larsen <
Chris_Larsen@symantec.com>,
"cti@lists.oasis-open.org" <
cti@lists.oasis-open.org>,
Mark Davidson <
Mark.Davidson@nc4.com> Date: 03/01/2018
04:07 PM Subject: Re:
[cti] Re: [EXT] Re: [cti] Advertising a CSD version of STIX and TAXII Jason, That is exactly my point. It needs to be defined so people CAN put
in the accept header. Bret From: Jason Keirstead <
Jason.Keirstead@ca.ibm.com> Sent: Thursday, March 1, 2018 1:00:23 PM To: Bret Jordan Cc: Allan Thomson; Chris Larsen;
cti@lists.oasis-open.org; Mark Davidson Subject: Re: [cti] Re: [EXT] Re: [cti] Advertising a CSD version of
STIX and TAXII Yes but that string is just informational. Client code should not be making
any decisions based on whatever it says. If the client is doing that it's
probably semi-broken by design. " 1) Just request "version=2.1"
and the server could respond with "version=2.1" but the actual
content may be CSD02 from the server and the client may only support "CSD01" " No... if I request version=2.1, you can't return anything else. Returning
anything else is wrong. If I want to also support csd02, it should be an
entry in my accept header (see my example). - 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: Bret
Jordan <
Bret_Jordan@symantec.com> To: Jason
Keirstead <
Jason.Keirstead@ca.ibm.com>, Allan Thomson <
athomson@lookingglasscyber.com> Cc: Chris
Larsen <
Chris_Larsen@symantec.com>, "cti@lists.oasis-open.org"
<
cti@lists.oasis-open.org>, Mark Davidson <
Mark.Davidson@nc4.com> Date: 03/01/2018
03:51 PM Subject: [cti]
Re: [EXT] Re: [cti] Advertising a CSD version of STIX and TAXII Sent by: <
cti@lists.oasis-open.org> Actually that last statement is not true. In the API Root Resource
in TAXII, we advertise the version of TAXII that is supported. Further, your example exactly shows why this is a problem. If we
do not define the recommended way of doing this, then a client could do
one of the follow: 1) Just request "version=2.1" and the server could respond with
"version=2.1" but the actual content may be CSD02 from the server
and the client may only support "CSD01" 2) Request "version=2.1-csd-01" and the server either gives an
error because it supports "version=2.1-csd01" Bret From: Jason Keirstead <
Jason.Keirstead@ca.ibm.com> Sent: Thursday, March 1, 2018 12:05:21 PM To: Allan Thomson Cc: Bret Jordan; Chris Larsen;
cti@lists.oasis-open.org; Mark Davidson Subject: [EXT] Re: [cti] Advertising a CSD version of STIX and TAXII 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 <
athomson@lookingglasscyber.com> To: Chris
Larsen <
Chris_Larsen@symantec.com>, Mark Davidson <
Mark.Davidson@nc4.com>,
Bret Jordan <
Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org"
<
cti@lists.oasis-open.org> Date: 03/01/2018
02:39 PM Subject: Re:
[cti] Advertising a CSD version of STIX and TAXII Sent by: <
cti@lists.oasis-open.org> Agreed. To my point that it comes down to what the org cares about. Allan From: Chris Larsen <
Chris_Larsen@symantec.com> Date: Thursday, March 1, 2018 at 10:35 AM To: Allan Thomson <
athomson@lookingglasscyber.com>, Mark Davidson
<
Mark.Davidson@nc4.com>, Bret Jordan <
Bret_Jordan@symantec.com>,
"cti@lists.oasis-open.org" <
cti@lists.oasis-open.org> 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 <
athomson@lookingglasscyber.com> Sent: Thursday, March 1, 2018 11:28:32 AM To: Chris Larsen; Mark Davidson; Bret Jordan;
cti@lists.oasis-open.org 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 <
Chris_Larsen@symantec.com> Date: Thursday, March 1, 2018 at 10:15 AM To: Allan Thomson <
athomson@lookingglasscyber.com>, Mark Davidson
<
Mark.Davidson@nc4.com>, Bret Jordan <
Bret_Jordan@symantec.com>,
"cti@lists.oasis-open.org" <
cti@lists.oasis-open.org> 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:
cti@lists.oasis-open.org <
cti@lists.oasis-open.org> on
behalf of Allan Thomson <
athomson@lookingglasscyber.com> Sent: Thursday, March 1, 2018 10:37:42 AM To: Mark Davidson; Bret Jordan;
cti@lists.oasis-open.org 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 <
Mark.Davidson@nc4.com> Date: Thursday, March 1, 2018 at 9:30 AM To: Allan Thomson <
athomson@lookingglasscyber.com>, Bret Jordan
<
Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org"
<
cti@lists.oasis-open.org> 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 - why is 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: <
cti@lists.oasis-open.org> on behalf of Allan Thomson <
athomson@lookingglasscyber.com> Date: Thursday, March 1, 2018 at 12:13 PM To: Bret Jordan <
Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org"
<
cti@lists.oasis-open.org> 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: "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org>
on behalf of Bret Jordan <
Bret_Jordan@symantec.com> Date: Thursday, March 1, 2018 at 9:06 AM To: "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org> 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.