Re: [cti-taxii] HTTPS implementation language

["Mr. Stefan Hagen" <stefan@hagen.link>]

TL;DR I second Jason's rant ...

and would like to exacerbate on his points and repeat my suggestion of a strategy to deal with split capabilities in servers and clients we target ;-)


A) TLS v1.2

On lock-in on TLS 1.2 I start to shiver - adding positive problem case: TLS 1.3 will be ready someday, and then ...?


B) Mandate vs. prescribe

During "my" very first CTI weekly TC call, we discussed normative statements in the proximity of a split along "cleared receivers" and sender behavior, where I offered the possibility of delegating problematic mandate vs. prescribe issues into an escalating conformance grade split section. 

This is where IMO "stuff" belongs, in all "places" where there is a meaningful split in the set of targeted implementations.

I mentioned the OData targeting a range as servers from low level read only spread sheet up to database backed full update able matching conformance levels. (There we also allow for client implementations to adhere to matching conformance levels).

That strategy helps specification and implementation teams alike, in that it allows consistent, differentiated statements in the prose with focus per sub sets of the targeted objects to reach and claim conformance gradually aligned with capabilities, use cases and budget.


C) CRL and PKIX

I would suggest, at least a rewrite of:
"""A TAXII server MUST support CRLs and PKIX client certificates to claim TAXII compliance."""

split in two parts, in the describing prose:
1)
"""A TAXII server SHOULD support CRLs and PKIX client certificates. [label_or_production xyz]"""
and in the conformance section highlight
2)
"""A so and so high level conforming TAXII server MUST support CRLs and PKIX client certificates cf. [label_or_production xyz]"""

As usual the caveat applies, that I am not a native English speaker, so please adjust, as you seem fit.


All the best (and still off work until 3, January 2017),
Stefan.

On 28/12/16 00:13, Jason Keirstead wrote:
> I worry a lot about having such strict requirements for TAXII.  
> 
> I have said a few times on here in the past ( Dec 16 / 2015, June 3 2016
> ) that we want to be very careful here of what we mandate vs. what we
> prescribe.
> 
> I do not even think stating that a client MUST implement TLS 1.2 is a
> good idea because it opens the door to us having to emergency-revise the
> spec if and when there is a flaw discovered in TLS 1.2
> 
> I especially do not agree with the mandate that a TAXII server MUST
> support CRLs and PKIX client certificates to be claim TAXII compliance.
> What if I only want to support JWT for authentication?
> 
> -
> 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
> 
> 
> 
> 
> From:        Eric Burger <Eric.Burger@georgetown.edu>
> To:        cti-taxii@lists.oasis-open.org
> Date:        12/23/2016 12:37 PM
> Subject:        [cti-taxii] HTTPS implementation language
> Sent by:        <cti-taxii@lists.oasis-open.org>
> ------------------------------------------------------------------------
> 
> 
> 
> DRAFT
> 
> 2.  HTTPS Requirements
> 
> The TAXII Protocol defined in this specification requires HTTPS as the
> transport for all communications.
> 
> ·      TAXII Servers and Clients MUST implement HTTPS [RFC7230].
> 
> ·      TAXII Servers and Clients MUST implement TLS version 1.2 [RFC5246].
> 
>                 o   TAXII Servers and Clients SHOULD implement later
> versions when available.
> 
> ·      TAXII Servers MUST implement PKIX X.509 certificates and
> certificate revocation lists [RFC5280 and RFC6818].
> 
> ·      TAXII Servers MUST support authenticating certificates using PKIX
> [RFC6125].
> 
>                 o   TAXII guarantees TAXII Clients can use at least PKIX
> (see above).
> 
> ·      TAXII Servers and Clients MAY support other certification
> verification policies such as:
> 
>                 o   Certificate Pinning: A single or limited set of
> either hard-coded or physically distributed pinned certificate
> authorities or end-entity certificates.
> 
>                 o   DANE: DNS-based Authentication of Named Entities
> [RFC7671]
> 
>                 o   Note that Self-Signed Certificates (like other
> certificates which cannot be verified by PKIX) MAY be supported via
> Certificate Pinning and/or DANE as noted above for limited, closed user
> group applications.
> [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
> 
>