Re: [EXT] [cti-taxii] TAXII 2 URLs and Mandatory Discovery URL

Jason,

Please make sure issues are created for each of these in the issue tracker.

As I have stated in slack, but will state here for public record. I am not against making changes, even breaking changes, for TAXII 2.1 to fix problems, oversights, of things we just flat out got wrong. Personally what I want to avoid is making breaking changes more than once.

I feel like TAXII 2.0 was a first cut of an MVP committee specification release (some thing a bit more formal than just a draft). We knew some of it was solid and some of it was a bit squishy. Now that we have more people implementing TAXII 2.0, we have a better idea about things that need to be addressed and fixed. Also TAXII 2.0 is just a CS release, meaning it is still just a committee specification, not a full OASIS Standard.

So I would ask that we try and figure out all of the things that we got right and the parts that we got wrong, and fix all of them in TAXII 2.1. I would like TAXII 2.1 to be the "production" worthy release that we could take to a full OASIS Standard.

Bret

Hi everyone. I raised these concerns on Slack at the tail end of 2017, but thought i should send to the list as everyone has probably forgotten about them at this point.

I am discovering some real implementation issues with TAXII 2 as it is defined today - namely around two things

- The mandatory "/taxii" discovery root
- The fact that we do not specify if URLs can be relative, or if they must be absolute.

The issue is, the spec is written around the idea that someone hosting a TAXII 2 server

- Knows their host name and web root
- Has full control over the root web server hosting TAXII
- The /taxii endpoint does not already exist

None of these things are going to be true for a lot of implementations, where one is trying to add TAXII 2 support to an already existing product.

For (a) and (b), these provisions make it extremely difficult to implement a generic TAXII 2 support library vs. a full blown server. I have run into this myself trying to port the MITRE Medallion service to a library. If the library does not know where it is running, then it can't construct the full URLs the spec is expecting to be present in the discovery response

For (c), If you have https://my_api_gateway/taxiialready in use on your system for TAXII 1, then you actually can not implement TAXII 2 unless you make your TAXII 2 API run on a totally different VHost... something that is not always possible, *especially* for systems that are not registered in DNS and thus can't use VHost tricks.

I very strongly think we need to revisit some of this in TAXII 2.1. (c) to me is the biggest oversight we made and IMO is not an option to change, because folks use "/taxii" everywhere.

-
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

cti-taxii message