IMO what developers do while developing is out of scope for TAXII. TAXII’s requirements apply to implementations. IMO, HTTPS is a MUST for TAXII Servers to support. I’m OK with saying they MAY support HTTP.
At the end of the day, I want everything that says “I am compliant with TAXII” to be HTTPS-capable, at least at the implementation level. If two TAXII-compliant implementations wish to speak HTTP to each other, I’m fine with that.
Thank you.
-Mark
From: <
cti-taxii@lists.oasis-open.org > on behalf of "Foley, Alexander - GIS" <
alexander.foley@bankofamerica.com >
Date: Monday, February 22, 2016 at 11:04 AM
To: Adam Cooper <
adam.cooper@digital.cabinet-office.gov.uk >, John Anderson <
janderson@soltra.com >
Cc: Terry MacDonald <
terry@soltra.com >, "Jordan, Bret" <
bret.jordan@bluecoat.com >, Jason Keirstead <
Jason.Keirstead@ca.ibm.com >,
"
cti-taxii@lists.oasis-open.org " <
cti-taxii@lists.oasis-open.org >
Subject: RE: [cti-taxii] HTTPs
I also do not think we should mandate the use of HTTPS. To me this falls in the “allow people to shoot themselves in the foot” category of our various
discussions.
Alex
From:
cti-taxii@lists.oasis-open.org [ mailto:
cti-taxii@lists.oasis-open.org ]
On Behalf Of Adam Cooper
Sent: Monday, February 22, 2016 7:52 AM
To: John Anderson
Cc: Terry MacDonald; Jordan, Bret; Jason Keirstead;
cti-taxii@lists.oasis-open.org Subject: Re: [cti-taxii] HTTPs
Signed not encrypted. It's integrity that I'm talking about not confidentiality.
As for developers - just don't sign in dev. I've been doing this in SAML dev for years without issue.
On 22 February 2016 at 12:48, John Anderson <
janderson@soltra.com > wrote:
Signed messages + enforced encryption? That's even
more load on development. Please, let's lighten the load on developers. (I have enough XML-DSIG scars already, thank you.)
Terry, I like your idea. Certification bodies can add whatever arbitrary requirements they want. If developers care about getting their systems certified by the Secret
Squirrel Club, then they can pay the extra cost to implement the Nut Cracking Encryption requirement. If they don't care about that certification, they're not forced to do extra busywork. (That way, you get somewhat of a Free Market Effect going.)
JSA
From: Adam Cooper <
adam.cooper@digital.cabinet-office.gov.uk >
Sent: Monday, February 22, 2016 4:28 AM
To: Terry MacDonald
Cc: John Anderson; Jordan, Bret; Jason Keirstead;
cti-taxii@lists.oasis-open.org Subject: Re: [cti-taxii] HTTPs
As a further thought on the data integrity theme - HTTPS / TSL is arguably not strong enough anyway and we should also consider cryptographically signing
messages negating as well as protecting the transport layer.
On 22 February 2016 at 09:13, Adam Cooper <
adam.cooper@digital.cabinet-office.gov.uk >
wrote:
Hi all,
I have to agree with Brett that data integrity must be a major concern and should be catered for in the spec. To avoid naming specifics like HTTPS, TLS
version, algorithms etc, we could consider an outcome based description of the requirement for data integrity allowing. As an alternative we could simply refer to a separate compliance spec that can be iterated over time.
As for John's concerns for developers using finding it painful to use HTTPS in dev... I know what you mean but this is for vendors and implementers to
solve and frankly it's not that hard to fix in dev. It certainly shouldn't be a reason for having no integrity for the data.
The suggestion from Terry is interesting but this leaves protection of data integrity as an optional requirement which is not strong enough in my opinion.
Thanks,
Adam
On 22 February 2016 at 07:45, Terry MacDonald <
terry@soltra.com > wrote:
What about making it optional in the spec, but mandatory in the validation/certification? It would allow the turning off of the TLS during development, but
the tooling would require TLS on by default out of the box to be certified TAXII2 compliant.
Would that suffice?
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA An FS-ISAC and DTCC Company
+61 (407) 203 206
terry@soltra.com From:
cti-taxii@lists.oasis-open.org [mailto:
cti-taxii@lists.oasis-open.org ]
On Behalf Of John Anderson
Sent: Monday, 22 February 2016 1:25 PM
To: Jordan, Bret <
bret.jordan@bluecoat.com >; Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Cc:
cti-taxii@lists.oasis-open.org Subject: Re: [cti-taxii] HTTPs
Reason #1 for allowing plain-HTTP sessions: Development sanity.
Recommending HTTPS in Production...no problem. Requiring it during development => nuts.
Setting a policy among your own Trust Group to require HTTPS...reasonable and enforceable. Mandating this in the spec and implementing it in a reference library =>
more forks and monkeypatches, yay!
Nuf said.
JSA
From:
cti-taxii@lists.oasis-open.org <
cti-taxii@lists.oasis-open.org > on behalf of Jordan, Bret <
bret.jordan@bluecoat.com >
Sent: Sunday, February 21, 2016 7:24 PM
To: Jason Keirstead
Cc:
cti-taxii@lists.oasis-open.org Subject: Re: [cti-taxii] HTTPs
I think the risk to data integrity makes this critical. I think we live in a day and age where everything should be encrypted by default and we should define a base level of encryption,
to set some lines in the sand.
This protects organizations, protects content in transit from manipulation, and ensures clients can talk to servers. You say "we should not mandate HTTPs at all". I would flip that
question around and say is there a reason to NOT do encrypted sessions.
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 Feb 21, 2016, at 16:50, Jason Keirstead <
Jason.Keirstead@ca.ibm.com > wrote:
I am actually starting to migrate to the camp that we should not mandate HTTPS at all. We should get out of that level of the stack.
For all we know people have TAXII deployed on a private IPSEC network or over a point to point tunnel.
-
Jason Keirstead
STSM, 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> "Jordan, Bret" ---02/21/2016 03:43:48 PM---Great points Jason... May I ask you to propose some replacement text? Thanks,
From:
"Jordan, Bret" <
bret.jordan@bluecoat.com >
To:
Jason Keirstead/CanEast/IBM@IBMCA
Cc:
"
cti-taxii@lists.oasis-open.org " <
cti-taxii@lists.oasis-open.org >
Date:
02/21/2016 03:43 PM
Subject:
Re: [cti-taxii] HTTPs
Sent by:
<
cti-taxii@lists.oasis-open.org >
Great points Jason... May I ask you to propose some replacement text?
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 Feb 21, 2016, at 15:49, Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
wrote:
Currently the spec has changed from "TAXII must require HTTPS" to "TAXII must require HTTPS TLS 1.2 with
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 and <insert two full
pages of text here>.
I very much disagree with us specifying TLS levels and ciper suites in our specification. There are many problems with this
- There will be vendors who do not have the ability to implement the prescribed suite for a variety of reasons, and if this is part of the spec we are basically saying those vendors can't implement TAXII.
- There will be consumers who will not want to implement the prescribed suite for a variety of reasons, and if this is part of the spec we are basically saying those consumers can't consume TAXII
- The minimally viable cipher suite viable today is not the same one that will be minimally viable 6 months from now, so the whole chapter is entirely pointless and actually can be counter-productive, as at that point it will be mandating an insecure baseline.
-
Jason Keirstead
STSM, 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> "Jordan, Bret" ---02/21/2016 02:11:53 PM---I am going to propose that TAXII 2.x does NOT allow non-encrypted communications and propose
that th
From: "Jordan, Bret" <
bret.jordan@bluecoat.com >
To: "
cti-taxii@lists.oasis-open.org " <
cti-taxii@lists.oasis-open.org >
Date: 02/21/2016 02:11 PM
Subject: [cti-taxii] HTTPs
Sent by: <
cti-taxii@lists.oasis-open.org >
I am going to propose that TAXII 2.x does NOT allow non-encrypted communications and propose that that text be removed form the pre-draft specs..
We asked for feedback on this issue several weeks ago, and have yet to hear anyone suggest a reason why TAXII 2.x needs to support non-encyprted HTTPs sessions (aka null ciphers)
If you believe TAXII 2.x should support non-encrypted sessions, please speak up and give us your use-cases.
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."
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
--
Adam Cooper
Identity Assurance Programme
Government Digital Service
125 Kingsway, London, WC2B
6NH
Tel: 07973 123 038
official:
adam.cooper@digital.cabinet-office.gov.uk official sensitive:
adam.cooper@govdigital.gsi.gov.uk --
Adam Cooper
Identity Assurance Programme
Government Digital Service
125 Kingsway, London, WC2B
6NH
Tel: 07973 123 038
official:
adam.cooper@digital.cabinet-office.gov.uk official sensitive:
adam.cooper@govdigital.gsi.gov.uk --
Adam Cooper
Identity Assurance Programme
Government Digital Service
125 Kingsway, London, WC2B 6NH
Tel: 07973 123 038
official:
adam.cooper@digital.cabinet-office.gov.uk official sensitive:
adam.cooper@govdigital.gsi.gov.uk This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer . If you are not the intended recipient, please delete this message.