OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-taxii message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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! &#X1f61d

 

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




--
Adam Cooper
Identity Assurance Programme
Government Digital Service
125 Kingsway, London, WC2B 6NH

Tel: 07973 123 038



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]