Re: [dtn] Erik Kline's No Objection on draft-ietf-dtn-tcpclv4-23: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Wed, Dec 02, 2020 at 10:34:27PM -0800, Erik Kline via Datatracker wrote:
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I'll not disagree with my predecessor, but "[[ discuss ]]" has some random
> thoughts that were rattling around in my head.
> 
> 
> [[ discuss ]]
> 
> [ section 4.* ]
> 
> * Instead of upgrading in-session to TLS after CH version and magic field
>   verification, Can the TLS session be negotiated first and perhaps quickly
>   closed based on some DTN-specific ALPN (perhaps "dtn")?
> 
>   Can the use of a DTN-specific ALPN be any help even with in-session TLS
>   upgrade (as currently described)?

This is an attractive idea, but seems like it would be quite messy in
practice -- it is (I assume) a goal to retain compatibility with older
TCPCL versions and negotiate the older one if needed, so even if you can
get away with trying TLS first, you still have to have a fall back to
plaintext; that, in turn, eliminates much of the security benefit of always
trying TLS.  What you end up with (AFAICT) ends up having the same
security properties as the current scheme, where you can have local policy
to always require CAN_TLS to be set, but otherwise you end up in a case
where you allow non-TLS connections based solely on unauthenticated traffic
on the wire (that is subject to tampering).

It's also tempting to define the "dtn" ALPN value, but then you have to
specify error handling for when you do the contact header exchange and
agree to start TLS, but then don't negotiate the "dtn" ALPN.  It just adds
another way to fail, and doesn't provide much value since the context of
the conact header already gives a strong indication of what you intend to
speak.

-Ben