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

[Benjamin Kaduk <[e-mail]>]

Hi Ran,

In short: I agree with what you write.

On Tue, Oct 27, 2020 at 10:42:31AM -0400, R. Atkinson wrote:
> 
> 
> > On Oct 26, 2020, at 23:49, Brian Sipos <[e-mail]> wrote:
> 
> > It's also inconsistent with a desire
> > to make TLS support mandatory to implement (but not mandatory to use),
> > since mandatory to implement implies mandatory to be "capable of
> > exchanging messages with TLS", thus mandatory to use.
> 
> The quote above is a confusion, I think. 
> 
> Please bear with me while I try to explain why that claim about “mandatory
> to use" is only a confusion, not what “mandatory to implement” actually means.
> 
> The key distinction is that “mandatory to implement” means something must
> be fully implemented and supported in the code (or logic if one were to have a
> a Verilog implementation), but it does NOT mean that it have a default run-time 
> configuration of “security is enabled”.

Exactly.  I am (I think) complaining about the specific connotations of the
words used in the description of setting CAN_TLS, and am not trying to say
that the code always will have a default run-time configuration of
"security is enabled".

Specifically, the -23 has:

   If an entity is capable of exchanging messages according to TLS 1.3
   [RFC8446] or any successors which are compatible with that TLS
   ClientHello, the the CAN_TLS flag within its Contact Header SHALL be
   set to 1.  [...]

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), 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!  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".

Thanks,

Ben

> As a trivial example, possibly unrealistic in life but still useful for understanding...
> 
>  Some implementation (which I will call “X”) of DTN implements support for BPsec
>  and TLS, but it also has a *user* (or maybe system administrator) configurable 
>  switch which allows TLS to be enabled or disabled for a given system which has
>  that implementation X installed on it.
> 
>  Such a switch might have various degrees of granularity,  It could be set
>  to default to respond to TLS but not initiate TLS.  It could be set to try to
>  initiate TLS but continue without TLS if the other end is not willing to do TLS.
>  Ideally, it would enable security to be invoked on a per DTN-session basis,
>  perhaps through some API.
>  
>  As an example from another protocol family, one’s smart phone handset almost
>  certainly _implements_ AH, ESP, and IKE.  That doesn’t mean that the handset
>  will respond to an unsolicited IKE initiation packet from an unknown remote IP
>  address.  Many IPsec deployments have been _configured_ to ignore unsolicited
>  IKE packets, for example.  One’s smart phone likely drops unsolicited / unexpected
>  incoming IKE initiation packets, unless it has been configured otherwise in some
>  manner.  
> 
>  (Example: For an iPhone, the “managed deployment” software generally provides
>  ways for a corporate IT department to automatically bring up an IPsec VPN, an
>  SSL/TLS VPN, or to have some security-protocol policies configured a certain way
>  inside the smart phone handset.)
> 
>  Common UNIX implementations of AH, ESP, and IKE use setsockopt() to enable
>  and/or configure the use of AH or ESP for a given IP session.  On my Mac, the
>  most immediately relevant man pages (man pages are only accessible if one has 
>  developer tools installed on MacOS, AFAIK) are:
>      setsockopt(2)
>      sysctl(8)
>      ipsec(4)
> 
>  On other flavours of UNIX, the relevant set of man pages might vary.
> 
>  So to use IPsec for a given IP session, one probably has a line of code which
>  invokes setsockopt() with the applicable socket option to enable IPsec.  This
>  might manifest in an application as a command-line switch or flag, for example.
> 
> So, to be very clear, the IETF meaning of “mandatory to implement” is that ALL
> implementations must support the feature/capability.  It does NOT mean that a
> given _deployment_ of that implementation on a _particular system_ is required 
> to configure that capability to be on by default.
> 
> Yours,
> 
> Ran
> 
>     
>  
> 
>