Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Wed, Nov 18, 2020 at 10:38:57PM -0500, R. Atkinson wrote:
> 
> 
> > On Nov 16, 2020, at 20:10, Benjamin Kaduk <[e-mail]> wrote:
> > 
> > If we say that TLS support is "mandatory to implement" (do we?  I couldn't
> > find such text in a quick search, but thought we had talked about it),
> 
> Hi,
> 
> I don’t see any text saying that TLS is “mandatory to implement” in the TCPCL I-D.  
> 
> I believe the TCPCL I-D should have text, probably in Security Considerations, saying that:
> 
> "TLS is mandatory to implement for all TCPCL implementations, but TLS is optional to use for a given TCPCL session."
> 
> I imagine the WG would be comfortable with words generally along those lines, but I am not sure whether a formal WG decision has been made. (DTN Chairs ?)

I would be very happy if something like that could be added.

> > it would require some very convoluted reasoning to come up with a scenario
> > where an entity is "not capable of exchanging messages according to TLS
> > 1.3" -- it would be right in the spec that your implementation needs to
> > have the capability to do so!  
> 
> Agreed.
> 
> > Yes, we could come up with some explanation about local policy clamping the implementation's capabilities, but it seems like it would be simpler to use a slightly different wording here, like
> > “if the entity is configured to enable exchanging messages according to TLS
> > 1.3" that does not set up an apparent conflict between "capable" and
> > "implements”.
> 
> That text edit would work for me.  
> 
> Effectively those edits would mean that all TCPCL implementations would need to implement TLS (which implementation really is easy since OpenSSL exists and could be used) but that local configuration might mean TCPCL is not in use for some TCPCL sessions.

Agreed.

> As an aside, many commercial vendors use OpenSSL as the basis for their TLS implementations, in part because OpenSSL already has a FIPS-140 approval from US NIST.  This makes compliance with both US and non-US buyer requirements easier for vendors.  FIPS-140 is commonly required by non-US financial institutions and a range of countries other than the US, so it is not really a US-specific sales/acquisition issue.

Stepping aside even further, for my day job I work on OpenSSL, and the
existing FIPS-140 certificate is for a module that only works with an
OpenSSL version that is no longer officially supported.  We (mostly not me
personally) are making a bit push to get a new one along with the 3.0 major
release (currently in alpha), and the people doing most of the work are in
Australia, the UK, and Sweden -- not the US!

-Ben