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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 27 Jan 2021 21:03:36 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dtn-tcpclv4-24: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/

----------------------------------------------------------------------
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.

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.)

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.

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.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Jan 2021 15:45:11 +0000

Thanks Ben,

Authors, can you please look through these comments and it looks like some text
changes would be appropriate before this is approved. Can you please suggest
such changes or clarify why you think they shouldn't be addressed?

Cheers

Magnus