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


The solution just hacked out (proposed, not accepted yet) in STIR is to have two documents. One describing the protocol, which points to another, that describes the MTI security features. That way one can change the security features (e.g., TLS 3.9 instead of TLS 1.2) without touching the base protocol document. Former document is tens of pages (describing TAXII). Later document is a few pages (mandatory security protocols and their respective interoperability instructions).

On Dec 16, 2015, at 11:24 AM, Eric Burger <Eric.Burger@georgetown.edu> wrote:

Precisely. The point is we do not have a crystal ball. Also, saying “highest version of SSL available” is not actionable and does not enable interoperability. It does not mean anything to anyone.

"MUST implement SSL 1.0" does all of that, and by now an errata that says "MUST reject SSL 1.0 and MUST implement TLS 1.2" is sufficient to ensure security and interoperability.


On Dec 16, 2015, at 11:21 AM, Mark Davidson <mdavidson@soltra.com> wrote:

Regarding HTTPS – My hope is that we can find some language that is relevant both today and tomorrow. Of particular note, what specification could have anticipated the shift from SSL to TLS? A spec that required “the highest version of SSL available” would be woefully behind today’s technology stack.

Thank you.
-Mark

From: <cti-taxii@lists.oasis-open.org>, Eric Burger <ewb25@georgetown.edu> on behalf of Eric Burger <Eric.Burger@georgetown.edu>
Date: Wednesday, December 16, 2015 at 11:09 AM
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Subject: Re: [cti-taxii] HTTPS

Brilliant minds think alike. I just had this very exchange on the STIR list, where I was the one saying what you said. The answer is that no matter what, once the hole in TLS 1.2 gets exposed, we will need to issue new guidance anyway. The point of having a MUST now is to establish the bottom baseline and set the least common denominator for downgrade attacks.

On Dec 16, 2015, at 9:59 AM, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

Just want to play devils advocate - one problem with having things like "MUST support TLS 1.2" in a standard vs. leaving it more open-ended, is what happens if/when TLS 1.2 has a gaping hole discovered in 6 months... we now have a standard mandating that people implement an insecure protocol, until we revise the standard.


-
Jason Keirstead
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>Eric Burger ---12/16/2015 10:55:52 AM---I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so

From: Eric Burger <Eric.Burger@georgetown.edu>
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 12/16/2015 10:55 AM
Subject: Re: [cti-taxii] HTTPS
Sent by: <cti-taxii@lists.oasis-open.org>





I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so there is lots of code to reuse, steal, or just run out-of-the-box.

One word of warning: specifying HTTPS requires a bit more work than just saying “MUST implement TLS 1.2.” We need to specify what servers and clients should expect in the Subject field, any limitations or MTI’s for cypher suites, etc. For example, for the open server TAXII case, I would say we would still require HTTPS, but allow the NULL cypher suite. That gets us some level of client and identity, as well as GZIP for free (well, paid for). That will also eliminate the mistaken thought that we need to allow HTTP access for open servers. Other things to specify is either requirements or implementation suggestions for what to do with self-signed certificates, etc.

I know, “send text.” I may get to it over the break if someone does not jump in before me.
      On Dec 16, 2015, at 5:48 AM, Adam Cooper <adam.cooper@digital.cabinet-office.gov.uk> wrote:

      I would advise specifying TLS v 1.2 or higher rather than 1.1.

      There seems no reason not to go for v1.2.


      On 16 December 2015 at 10:24, Jerome Athias <athiasjerome@gmail.com> wrote:
        TAXII systems MUST use TLS version 1.1 [RFC4346] or higher for
        confidentiality, identification, and authentication, when sending
        TAXII messages over HTTPS. HTTPS is specified in Section 2 of
        [RFC2818].

        NB: stolen from
        https://www.rfc-editor.org/rfc/rfc6546.txt

        2015-12-15 21:40 GMT+03:00 Jordan, Bret <
        bret.jordan@bluecoat.com>:
        > Please propose some updated verbiage...
        >
        >
        > 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 Dec 15, 2015, at 11:35, Jerome Athias <
        athiasjerome@GMAIL.COM> wrote:
        >
        > Hi,
        >
        > Thanks for asking.
        > Yes I think we should specify/highly recommend TLS
        >
        > My favorite resource:
        >
        https://www.feistyduck.com/books/bulletproof-ssl-and-tls/
        >
        > Cheers
        >
        > On Tuesday, 15 December 2015, Jordan, Bret <
        bret.jordan@bluecoat.com> wrote:
        >>
        >> All,
        >>
        >> Currently in the pre-draft document we have the following verbiage.
        >>
        >> This specification defines requirements for using HTTPS; this
        >> specification does not define requirements for using non-encrypted HTTP. All
        >> TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS.
        >>
        >>
        >> Question:
        >> Do we need to add anything extra about specific types of HTTPS, TLS
        >> version, etc?
        >>
        >>
        >> 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."
        >>
        >

        ---------------------------------------------------------------------
        To unsubscribe from this mail list, you must leave the OASIS TC that
        generates this mail. Follow this link to all your TCs in OASIS at:

        https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



      --
      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






Attachment: smime.p7s
Description: S/MIME cryptographic signature



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