Subject: Re: [dtn] Benjamin Kaduk's Yes on draft-ietf-dtn-tcpclv4-24: (with COMMENT)

From: Brian Sipos <[email-masked]>
Date: Mon, 1 Feb 2021 21:00:37 +0000

I will respond inline with "BS1:" prefix below.

On Wed, 2021-01-27 at 21:03 -0800, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dtn-tcpclv4-24: Yes
> 
> 
> ---------------------------------------------------------------------
> -
> COMMENT:
> ---------------------------------------------------------------------
> -
> 
> The new text on TLS usage and the certificate profile is really
> solid.
> A huge thanks for getting that put together.
> 
> I just have a few minor comments left after looking it over:
> 
> Section 3.4 has some nice discussion in the last paragraph of SNI
> usage
> for "virtual host" behavior.  It ends with a note that when distinct
> per DNS name/Node ID certificate are present, operation proceeds
> "using
> the SNI value from the peer to select which certificate to use". 
> This
> is true, but perhaps leaves a bit of subtlety unsaid when Node IDs
> are
> involved, since the SNI content is nominally just a DNS name.  If it
> is
> to be used to select (say) a certificate with only a Node ID, any
> mapping between DNS name and Node ID used to pick the Node ID based
> on
> the provided DNS name would necessarily be conveyed out of band from
> this protocol.  That may be obvious, in which case it should be left
> as
> is, but if not it might be worth a note that any relationship between
> DNS name (SNI) and Node ID used in certificate selection is out of
> scope
> of this protocol.
> 
BS1: There is a general statement in Section 1.1 "Scope" which reads:
The mapping of Node ID to potential convergence layer (CL) protocol and 
network address is left to implementation and configuration of the BP 
Agent and its various potential routing strategies.

This statement applies to using SNI also, but it is not obvious and a note will be added to clarify.

> The certificate profile in Section 4.4.2 notes that the full
> certification chain SHOULD be included; it is common (but not
> universal)
> that when we provide such guidance, we call out what is to be done
> with
> the root CA/trust anchor.  (Usually it is not sent, since the
> receiving
> party needs to have it already in order to validate the chain.)
> 
BS1: I am surprised when reading through chain uses (TLS, JWK/JOSE, COSE) that they don't mention what to do about the
last item of the chain (root CA).
I will add a statement "An entity SHOULD omit the root CA certificate (the last item of the chain) when sending a
certification chain, as the recipient already has the root CA to anchor its validation."

> Also relating to the certificate profile in Section 4.4.2, we list
> the
> three potentially relevant key usage values of digitalSignature,
> keyEncipherment, and keyAgreement.  The latter two are (IIUC) only
> relevant for TLS versions prior to 1.3, since in TLS 1.3 certificates
> are only used to sign the CertificateVerify message, with key
> exchange
> being performed in a separate dedicated mechanism.  That said, it may
> still make sense to mention them here, since TCPCL really only
> requires
> the properties of TLS and does not make specific use (that I recall)
> of
> TLS 1.3.
> 
BS1: This is a good catch. The TLS 1.3 relevant key use will be clarified with a note about other key uses.

> Section 5.1.1 still seems to talk about the Keepalive Interval as
> being
> in the contact header, but it is actually in the SESS_INIT.
> 
BS1: This is a typo and will be fixed.