[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 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> 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
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.
From:
cti-taxii@lists.oasis-open.org <cti-taxii@lists.oasis-open.org> on behalf of Jordan, Bret <bret.jordan@bluecoat.com>
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."
--
Adam Cooper Identity Assurance Programme
Government Digital Service 125 Kingsway, London, WC2B 6NH Tel: 07973 123 038 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 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 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]