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

[Brian Sipos <[e-mail]>]

Ben et al.,
I've posted an updated draft which includes changes to address all but one of the latest SECDIR comments. The one remaining comment relates to when TLS is supposed to be negotiated for use:

I think we can also wordsmith the setting of CAN_TLS a little more;
previous discussion indicated a desire to (e.g.) not require TLS when
operating over IPsec, but that's a different criterion than "capable of
exchanging messages [with TLS]".  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.

For my own purposes and for public network use TLS would be expected, so I don't have a full idea of when TLS would be desirable to negotiate away. Would a more generic statement, inverting the current logic, such as the following work?

When sufficient security is not supplied by network layers under TCPCL, the the CAN_TLS flag within its Contact Header SHALL be set to 1.
When CAN_TLS flag is set to 1, the peer SHALL be capable of exchanging messages according to TLS 1.3 [RFC8446] or any successors which are compatible with that TLS ClientHello.

Thanks,
Brian S.
________________________________
From: Benjamin Kaduk <[e-mail]>
Sent: Wednesday, September 30, 2020 21:54
To: Brian Sipos <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

Hi Brian,

My deepest apologies for being so slow to respond.  I know excuses do not
help, but there were a number of things in my personal situation that came
up and kept my time scarce, and I am sorry that this lingered so long as
merely a "I want to do that" item and not "I am doing that".

Thank you for your responses; I think we are making good progress but still
need to settle on the specifics of the authentication procedures.  I'll
respond inline here, but I also have prepared a "standalone" writeup of
what I see as the remaining issues that I will post as a new ballot
position in the datatracker after I send this.  The semantic content should
be the same, so feel free to respond only in one place and ignore the
other.

On Fri, Mar 06, 2020 at 05:10:35AM +0000, Brian Sipos wrote:
> Benjamin,
> Thank you for the detailed feedback here!
>
> I'm including responses below with prefix "BS: "
>
> On Wed, 2020-02-19 at 14:45 -0800, Benjamin Kaduk via Datatracker wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-dtn-tcpclv4-18: Discuss
> >
> > 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=02%7C01%7CBSipos%40rkf-eng.com%7C90f578c09ad54fcf7dc708d865acec81%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637371140684000399&amp;sdata=WXawiXDXvYyif9vX60fmfZte70%2Bp%2BsvbcBc7kXaDdL0%3D&amp;reserved=0
> >
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dtn-tcpclv4%2F&amp;data=02%7C01%7CBSipos%40rkf-eng.com%7C90f578c09ad54fcf7dc708d865acec81%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637371140684000399&amp;sdata=%2F5uHxrGqFihjrWChChIGA85xIVMihGin0q9Pl2s5LCM%3D&amp;reserved=0
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > In Section 4.2 we say that "If an entity is capable of [...] TLS 1.2 or
> > any successors [...], the CAN_TLS flag within its contanct [sic] header
> > SHALL be set to 1."  I don't understand why we should allow in the spec
> > for an entity to not be capable of TLS 1.2+.  Can you give me some
> > examples of situations when you would want to use a TCPCL but cannot use
> > TLS with it?  A new major version of TCPCL would be the least-bad time
> > to make a clean break and mandate TLS...
> >
> BS: The WG made a positive decision to make TLS as mandatory-to-implement but
> not mandatory-to-use. The main reason was that TCPCL will be used in
> environments where the network itself is trusted (e.g. IPSEC) and where the
> entities are so lightweight that a TLS library is not available.
> I don't disagree with the sentiment though, which is why USE_TLS is required
> where a TLS library is available and the recommended policy is to require Enable
> TLS with a peer.

I guess that it makes sense to skip TLS if you already have IPsec or
something you're similarly confident in.  The current wording doesn't seem
to match up with your statement about MTI but not MTU, though -- "is
capable of" seems to condition on "implemented" and I'm not seeing a clear
statement about "mandatory to implement" In the text.

> > There's some good discussion in Section 4.4.2 of the mechanics of TLS
> > X.509 certificate authentication; thanks for that!  I do think that
> > there's a fairly critical omission, though, namely that the BP agent
> > needs to provide to the TCPCL Entity the Node ID of the expected next
> > hop from the routing decision (in addition to the hostname/IP address to
> > which to initiate a TCP connection), and this Node ID must also be
> > validated against the TLS certificate and the SESS_INIT from the peer.
> > Otherwise we are in effect falling back to an authorization policy of
> > "anyone with a cert with a uniformResourceIdentifier SAN of the expected
> > scheme is authorized to do anything", which is a pretty weak policy.
> > (In some sense, if we require this, then the Node ID in the SESS_INIT
> > becomes redundant, though I think there are some edge cases where it
> > would still be needed in order for both endpoints to agree on the
> > communicating identities.)
> >
> BS: In some ways the Node ID is a carry over from earlier TCPCLv3 and you are
> correct about begging the question of whether the peer Node ID is authorized to
> send or receive bundles.
> Because the TCPCL is bidirectional and is symmetric after the session is
> established (bundles can transfer in either direction with identical logic and
> the recommended TLS logic is to authenticate in both directions) it seems like
> this kind of authorization is more a policy of the BP Agent than the TCPCL
> entity. Individual implementations could optimize the peer rejection during TLS
> handshake based on an expected Node ID, but this would be opaque to the on-the-
> wire activity.
> My feeling is to add this as a Security section threat of bundles being
> transferred to or from unauthorized peer nodes.

Leaving authorization checks as largely the role of the BP Agent seems
fine, as does having some discussion in the security section about not
handling bundles from peers unauthorized to give them to you or receive
them.

I do still think that we need to be more clear about the mechanics of how
the authentication process works, in terms of what is the input, what is
the output, and what things local policy is allowed to do.  (More below.)

> > I also think we need to discuss the TLS X.509 authentication model that
> > will be used, i.e., "what PKI is being used?".  (To be clear, I don't
> > know that any changes to the text will be required, but do think we
> > should be sure we have a clear picture of what the expected deployment
> > strategies are.) The usage of SNI to pick a cert and the DNS-ID (RFC
> > 6125) to authenticate a hostname might imply that the typical "Web PKI"
> > (that deals in hostnames) is intended, but the URIs we need to
> > authenticate Node IDs are not commonly certified by that PKI.  Since the
> > server has to present a single certificate even if it is attempting to
> > authenticate as both DNS-ID and the NodeID URI, it seems like it would
> > be challenging to use this scheme in practice against the Web PKI roots.
> > This hybrid of hostname and Node-ID authentication also suffers from an
> > awkward ordering issue when the TLS handshake occurs before the
> > SESS_INIT messages that convey what Node ID is intended to be
> > authenticated -- this requires implementations to use a TLS stack that
> > preserves the peer's certificate and perform name validation after a
> > completed TLS handshake, which is moving more of the complications out
> > of the TLS stack and into the application logic (which introduces risk
> > of security-relevant bugs).  It also means that certificate selection
> > must be based solely on SNI hostname and cannot involve the requested
> > Node ID.  [There is in theory the selectable name_type field in the TLS
> > server_name extension, but in practice that joint has rusted shut and it
> > seems unlikely that there would be much implementation traction to
> > define a name type for DTN Node ID; RFC 6066 also fails to give a clear
> > indication of the intended semantics when multiple name types are
> > present.]
> >
> BS: The reason for allowing other-than-Node-ID TLS authentication in the first
> place is to allow using the TCPCL/TLS in a "web PKI" type environment, because I
> know many CAs have strict policies about extension content and can be very
> inflexible about things like alternative SANs.
> I think the text can be more explicit in the non-requirement text about that
> prioritization of:
> 1. Node ID SAN when possible
> 2. DNS-ID SAN when available
> 3. IP address SAN when necessary
>
> And because the Node ID authentication likely happens in the application (as you
> mention) the logic is intentionally very simple URI matching.
> Because the DNS-ID authentication is not preferred, the use of SNI to is really
> a "use it when necessary" to handle inflexible CA policies. The expectation is
> that a single Node will still have a single Node ID but may need to use multiple
> DNS-ID-authenticating certificates to present itself between networks.
>
> If all that sounds reasonable, I need to spend a little time wordsmithing some
> non-requirement text to explain it.

I think your prioritization makes sense (and I really like the text you put
in as §4.1.1 about entity authentication), but I think that the §4.4.3 in
the -21 doesn't quite cover what we need.  In particular, while we do have
the clear prioritization of authentication mechanisms, if we make the
choice of which one to use depend on the certificate that the peer gives
us, we are open to an attacker giving us a weaker authentication type even
when the legitimate peer should possess the stronger one.  That is, the
attacker would get a DNS-ID cert and only need to convince you to talk to
that name, to be able to spoof traffic for an arbitrary Node ID, including
those Node IDs for which the correct peer has a cert with a NODE-ID in it.
So there needs to be an initial policy step to determine, for a given peer
node ID, what mechanism(s) are to be used, which then makes the validation
procedure simpler.  I would tend to expect policy to pick exactly one name
type to use, but there's in principle nothing preventing more complex
policies.

I don't know what the best way to do this will be, but I did do a bit of
brainstorming to start thinking about what is appealing; options could
include:

(a) any given node either always or never requires NODE-ID
(b) any given interface either always or never requires NODE-ID
(c) push it to the discovery protocol/"out of band configuration"
(d) a trust-on-first-use-like option of "once you've seen a NODE-ID for
  a given node ID, always require NODE-ID in the future for that node
  ID.  (This has pretty significant risks without a way to "undo the
  latch" but if generating a new node ID is cheap they may be
  tolerable.)
(e) define new URI scheme(s) that have similar semantics to the current
  ones but require NODE-ID for authentication.
(f) similar to (e), apply additional granularity based on URI scheme or
  scheme-specific structure (e.g., certain prefixes/suffixes of names
  but not others


> > Please double-check for lingering text that assumes the RFC 7242
> > behaviors where all parameters are in the contact header (vs. SESS_INIT)
> > and use of SDNV encoding vs. fixed-lengths.  I noted several instances
> > in the COMMENT section, but do not claim to have made an exhaustive
> > review.
> >
> BS: For an earlier comment I moved the Enable TLS up to the contact negotiation
> where it belongs and added an explicit requirement about using network byte
> order for all encoding.

Sounds good.  I think there might be a couple lingering instances in
sections 4.7 and 5.1.1, maybe about Keepalive Interval and the MTUs.

> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Please consider the comments from the secdir telechat review.
> >
> > Abstract
> >
> >    This document describes a TCP-based convergence layer (TCPCL) for
> >    Delay-Tolerant Networking (DTN).  This version of the TCPCL protocol
> >    is based on implementation issues in the earlier TCPCL Version 3 of
> >    RFC7242 and updates to the Bundle Protocol (BP) contents, encodings,
> >    and convergence layer requirements in BP Version 7.  Specifically,
> >
> > nit: I would hope that it's the changes in this version that are
> > intended to resolve implementation issues from the previous version, and
> > not some explicitly-operations-unfriendly protocol that seeks to
> > maximize implementation issues in deployment ;)
> >
> BS: Agree about phrasing and am updating the abstract.
>
> > Section 1.1
> >
> >    o  Mechanisms for locating or identifying other bundle entities
> >       (peers) within a network or across an internet.  The mapping of
> >       Node ID to potential CL protocol and network address is left to
> >
> > nit: I don't think even draft-ietf-dtn-bpbis even really defines "CL" as
> > an acronym (just "CLA"), so we should probably expand it somewhere.
> >
> BS: Added an abbreviation expansion here for clarity.
>
> >    o  Policies or mechanisms for assigning X.509 certificates,
> >       provisioning, deploying, or accessing certificates and private
> >       keys, deploying or accessing certificate revocation lists (CRLs),
> >       or configuring security parameters on an individual entity or
> >       across a network.
> >
> > In a similar vein to my Discuss points, I think I'm going to need some
> > more convincing that (some of) these are best left out of scope.  To
> > help me understand the current ecosystem, could you give me some
> > pointers to what has actually been used for deployments?  The security
> > of the system as a whole rests on the criteria used by CAs on whether to
> > certify a given public key as being associated with a Node ID (or host
> > name) and the trustworthiness of the CAs to apply those rules accurately
> > and without error.  (Perhaps this is not what you meant by "assigning
> > X.509 certificates", though.)
> >
> BS: Unfortunately we are getting into new territory with this highly-specified
> use of TLS. Earlier TCPCLv3/TLS use was ad hoc and network-dependent. I suspect
> that the use of a URI SAN to authenticate the Node ID is also new behavior.
> Do you think that some additional Security section text about the obligations of
> a CA to issue a certificate to a particular Node ID? Maybe a threat of "Misuse
> of a Properly Issued Certificate"? That's not really the threat itself but an
> attack vector though.

It looks like some of this got wrapped into section 3.4 (which I'll say
again: I really like!).  The other stuff we can probably live without (I'm
not entirely sure what would go in the "Misuse of a properly issued
certificate" section, off the top of my head).

> >    o  Uses of TLS which are not based on X.509 certificate
> >       authentication (see Section 8.10.2) or in which authentication is
> >       not available (see Section 8.10.1).
> >
> > Section 4.2 seems to describe "opportunistic TLS" and reference RFC
> > 7435, so I don't think we need to say "or in which authentication is not
> > available" here.
> >
> BS: I'm changing the text "... in which authentication is not available ..." to
> "... in which authentication of both entities is not possible ..." but the TCPCL
> really relies on TLS auth'n to ensure both peers have valid Node IDs.

I think it's worth spending a bit of time to check whole-document
consistency on this point, as IIRC there is some mention of continuing with
an unauthenticated peerr (at least, for a single identifier type); the
relevant text may be getting churned anyway given the earlier topic.

> > Section 2.1
> >
> >          A TCPCL Entity MAY support zero or more passive listening
> >          elements that listen for connection requests from other TCPCL
> >          Entities operating on other entitys in the network.
> >
> > nit: "entities"
> >
> BS: Fixed this typo.
>
> >          A TCPCL Entity MAY passivley initiate any number of TCPCL
> >          Sessions from requests received by its passive listening
> >          element(s) if the entity uses such elements.
> >
> > I'm not sure what "passively initiate" is supposed to mean.  Is this a
> > session initiation that's triggered by an incoming message in some
> > fashion?
> > Also, nit: "passively"
> >
> BS: That really means to "accept a TCP connection" to begin TCPCL negotiation.
> But from the protocol perspective there is not really such a thing as "accept".

I see your meaning, with the TCPCL sessions themselves being
unidirectional.

> >    TCPCL Session:  A TCPCL session (as opposed to a TCP connection) is a
> >       TCPCL communication relationship between two TCPCL entities.
> >       Within a single TCPCL session there are two possible transfer
> >       streams; one in each direction, with one stream from each entity
> >       being the outbound stream and the other being the inbound stream.
> >       The lifetime of a TCPCL session is bound to the lifetime of an
> >       underlying TCP connection.  A TCPCL session is terminated when the
> >       TCP connection ends, due either to one or both entities actively
> >       closing the TCP connection or due to network errors causing a
> >       failure of the TCP connection.  For the remainder of this
> >       document, the term "session" without the prefix "TCPCL" refers to
> >       a TCPCL session.
> >
> > This leaves me confused as to whether there is one TCP connection or two
> > between interacting entities ("two possible transfer streams" vs. "the
> > TCP connection ends") -- are the two transfer streams just the two
> > directions of the single TCP connection?
> >
> BS: I rephrased this paragraph for an earlier comment. The concept of a transfer
> stream is purely logical but it is helpful from the point of view of an
> implementer or a protocol inspector to understand that transfers in one
> direction are logically independent from the other direction. The messages are
> interleaved necessarily, as there is one TCP connection, but they are still
> logically separate.
> The new text includes the statement:
> A TCPCL session operates within a single underlying TCP connection
> and the lifetime of a TCPCL session is bound to the lifetime of
> that TCP connection.
>
> >    Idle Session:  A TCPCL session is idle while the only messages being
> >       transmitted or received are KEEPALIVE messages.
> >
> >    Live Session:  A TCPCL session is live while any messages are being
> >       transmitted or received.
> >
> > nit: any messages other than KEEPALIVE, I presume.
> >
> BS: For an earlier comment I clarified the Live vs. Idle state as being based on
> in-progress transmissions.
>
> >
> > In Figure 2, are any of the respective sessions 1 through n targetting
> > the same "other TCPCL Entity's Listener" or is the idea that they're 1:1
> > session:other-entity?  If they're 1:1, it might be worth trying to make
> > the arrow from #n go to the box in the background instead of the one in
> > the foreground.  (This potentially holds true whether the Acks are TCP
> > ACKs or XFER_ACKs.)
> >
> BS: There is actually no restriction in the number of TCPCL sessions between any
> two entities. In fact, if parallel simultaneous transfers are desired then more
> than one session is necessary.

Understood; thanks.

> > In Figure 3, if there's actually only one (bidirectional) TCP
> > connection, we might want to think about indicating the sequencing
> > between Acks and Segments in the same direction.
> >
> BS: It's difficult for the notional figure to capture all of the nuances and
> still be as schematic as I would like. Here is a go at making the figure more
> accurate to the protocol:
>
> +---------------------------+              +---------------------------+
> |    "Own" TCPCL Session    |              |   "Other" TCPCL Session   |
> |                           |              |                           |
> | +----------------------+  |              |  +----------------------+ |
> | |   TCP Connection     |  |              |  |    TCP Connection    | |
> | |                      |  |              |  |                      | |
> | | +-----------------+  |  |   Messages   |  |  +-----------------+ | |
> | | |   Own Inbound   |  +--------------------+  |  Peer Outbound  | | |
> | | | Transfer Stream |                          | Transfer Stream | | |
> | | |       -----     |<---[Seg]--[Seg]--[Seg]---|       -----     | | |
> | | |     RECEIVER    |---[Ack]----[Ack]-------->|      SENDER     | | |
> | | +-----------------+                          +-----------------+ | |
> | |                                                                  | |
> | | +-----------------+                          +-----------------+ | |
> | | | Own Outbound    |-------[Seg]---[Seg]----->|  Peer Inbound   | | |
> | | | Transfer Stream |<---[Ack]----[Ack]-[Ack]--| Transfer Stream | | |
> | | |       -----     |                          |       -----     | | |
> | | |      SENDER     |   +--------------------+ |     RECEIVER    | | |
> | | +-----------------+   |  |              |  | +-----------------+ | |
> | +-----------------------+  |              |  +---------------------+ |
> +----------------------------+              +--------------------------+

That looks improved.  (I think my written question here was predicated on a
false hypothesis, so is irrelevant.)

> > Section 3.1
> >
> >    Session State Changed:  The TCPCL supports indication when the
> >       session state changes.  The top-level session states indicated
> >       are:
> >
> > Is this an indication from the TCPCL Entity to the BP agent?  (Similarly
> > for "Idle Changed", etc.)
> >
> BS: From an earlier comment these all got clarified to read "The TCPCL entity
> indicates to the BP agent ..."
>
> >       ongoing transfer.  Because TCPCL transmits serially over a TCP
> >       connection, it suffers from "head of queue blocking" this
> >       indication provides information about when a session is available
> >       for immediate transfer start.
> >
> > nit: run-on sentence.
> >
> BS: I edited to hopefully fix this phrasing.
>
> >    Begin Transmission:  The principal purpose of the TCPCL is to allow a
> >       BP agent to transmit bundle data over an established TCPCL
> >       session.  Transmission request is on a per-session basis, the CL
> >       does not necessarily perform any per-session or inter-session
> >       queueing.  Any queueing of transmissions is the obligation of the
> >
> > nit: comma splice.
> >
> BS: Fixed this phrasing.
>
> >    Transmission Failure:  The TCPCL supports positive indication of
> >       certain reasons for bundle transmission failure, notably when the
> >       peer entity rejects the bundle or when a TCPCL session ends before
> >       transfer success.  The TCPCL itself does not have a notion of
> >       transfer timeout.
> >
> > I'm sure there is a subtle distinction here between a "TCPCL notion of
> > transfer timeout" and the underlying TCP connection timing out on
> > retransmissions, but I'm not sure what it is, yet.
> >
> BS: This paragraph is to say that a session ending for whatever reason (could be
> a TCP timeout, could be something else) is the cause of the transfer failure. If
> the session is kept alive (e.g. using TCP keepalive) a transfer could
> potentially last a very, very long time if the TCP throughput is low. If a BP
> agent wishes to impose a transfer timeout it can but that's not part of the
> TCPCL.
>
> > Section 3.2
> >
> >    negotiate the use of TLS security (as described in Section 4).  Once
> >    contact negotiation is complete, TCPCL messaging is available and the
> >    session negotiation is used to set parameters of the TCPCL session.
> >    One of these parameters is a Node ID of each TCPCL Entity.  This is
> >    used to assist in routing and forwarding messages by the BP Agent and
> >    is part of the authentication capability provided by TLS.
> >
> > I might phrase this as "the Node ID that each TCPCL Entity is acting
> > as".
> >
> BS: Corrected this phrasing.
>
> >    Once negotiated, the parameters of a TCPCL session cannot change and
> >    if there is a desire by either peer to transfer data under different
> >    parameters then a new session must be established.  This makes CL
> >    logic simpler but relies on the assumption that establishing a TCP
> >    connection is lightweight enough that TCP connection overhead is
> >    negligable compared to TCPCL data sizes.
> >
> > (I assume this assumption holds true ~universally for DTN TCPCL
> > consumers?)
> >
> BS: I can't speak for all deployments, but when TCP is the transport layer there
> is an assumption that establishing TCP connections is part of the price to pay.
> The point of TCPCL session keeping overhead is to hopefully avoid the session
> establishment overhead when multiple transfers are needed in a short enough
> time.
>
> >    There is no fundamental limit on the number of TCPCL sessions which a
> >    single node can establish beyond the limit imposed by the number of
> >    available (ephemeral) TCP ports of the passive entity.
> >
> > "epehemeral TCP ports" on the passive entity seems like a typo, as
> > Section 4.1 suggests that the passive entity usually uses the assigned
> > port 4556 and the source port on the active entity is an ephemeral one.
> >
> BS: This is a typo.
>
> >    Section 4.3).  Regardless of the reason, session termination is
> >    initiated by one of the entities and responded-to by the other as
> >    illustrated by Figure 13 and Figure 14.  Even when there are no
> >    transfers queued or in-progress, the session termination procedure
> >    allows each entity to distinguish between a clean end to a session
> >    and the TCP connection being closed because of some underlying
> >    network issue.
> >
> > [This is also useful for TLS connections, as proper usage of
> > bidirectional "close_notify" alerts is far from universal.]
> >
> > Section 3.3
> >
> > It would probably be worth expanding "PCH" and "PSI" on first use rather
> > than last use.
> >
> BS: Expanded this on first use.
>
> >    Contact negotiation involves exchanging a Contact Header (CH) in both
> >    directions and deriving a negotiated state from the two headers.  The
> >    contact negotiation sequencing is performed either as the active or
> >    passive entity, and is illustrated in Figure 5 and Figure 6
> >    respectively which both share the data validation and analyze final
> >    states of the "[PCH]" activity of Figure 7 and the "[TCPCLOSE]"
> >    activity which indicates TCP connection close.  Successful
> >
> > I'm not sure what "analyze final states" is intended to mean.  (It shows
> > up again later, in discussion of Figure 10.)
> >
> BS: The phrase "analyze final states" should read "negotiation" here.
>
> > Where does [PCH] occur in Figure 6?  (Should the "[PSI]" be changed to
> > "[PCH]"?)
> >
> BS: Yes this is a typo.
>
> > Several of the figures have "negotiate <X>" steps that do not have
> > possible paths for failure of negotiation; only Figure 4 seems to have a
> > disclaimer that it only shows the "nominal" case.
> >
> >    Session termination involves one entity initiating the termination of
> >    the session and the other entity acknowledging the termination.  For
> >    either entity, it is the sending of the SESS_TERM message which
> >    transitions the session to the ending substate.  While a session is
> >    being terminated only in-progress transfers can be completed and no
> >    new transfers can be started.
> >
> > Would it be more clear to say "is in the ending substate" than the
> > current "is being terminated"?
> >
> BS: Yes this is more clear.
>
> > Section 3.4
> >
> >    Each TCPCL session allows a negotiated transfer segmentation polcy to
> >
> > nit: "policy"
> >
> BS: Fixed this typo.
>
> >    be applied in each transfer direction.  A receiving node can set the
> >    Segment MRU in its contact header to determine the largest acceptable
> >
> > nit: this is in SESS_INIT now, not the contact header.
> >
> BS: Fixed this typo.
>
> >    attempt, and it SHOULD use a (binary) exponential back-off mechanism
> >
> > Thank you for specifying the base of the exponent!
> >
> > Section 4.1
> >
> >    established, the entity SHALL close the TCP connection.  The ordering
> >    of the contact header exchange allows the passive entity to avoid
> >    allocating resources to a potential TCPCL session until after a valid
> >    contact header has been received from the passive entity.  This
> >
> > I'm pretty sure that the passive entity is not going to get a contact
> > header from itself.
> >
> BS: Fixed this typo.
>
> > Section 4.2
> >
> > It might be worth discussing the invariants of the contact
> > header/protocol, akin to
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8446%23section-9.3&amp;data=02%7C01%7CBSipos%40rkf-eng.com%7C90f578c09ad54fcf7dc708d865acec81%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637371140684000399&amp;sdata=MrlUL2glCHU1tl2OmGBIEqfBNWNY8pVxCTJ616a1kR8%3D&amp;reserved=0
> >
> > (though presumably less complicated!), since we are changing how things
> > work between TCPCLv3 and TCPCLv4.
> >
> BS:

(I'm not sure if there was supposed to be something here that didn't get
added.)  At this point I don't feel strongly that there needs to be
discussion of invariants.

> >    If an entity is capable of exchanging messages according to TLS 1.2
> >    [RFC5246] or any successors [RFC8446] that are compatible with TLS
> >    1.2, the CAN_TLS flag within its contanct header SHALL be set to 1.
> >    This behavor prefers the use of TLS when possible, even if security
> >    policy does not allow or require authentication.  This follows the
> >    opportunistic security model of [RFC7435].
> >
> > When possible and there is not an active attack, which is an important
> > difference!
> >
> BS: Understood, but is it worthwile to indicate this in the text?

Well ... yes and no.  Maybe add at the end of the sentence ", though an
active attacker could interfere with the exchange in such cases"?

> > Section 4.3
> >
> >    The first negotiation is on the TCPCL protocol version to use.  The
> >    active entity always sends its Contact Header first and waits for a
> >    response from the passive entity.  The active entity can repeatedly
> >    attempt different protocol versions in descending order until the
> >    passive entity accepts one with a corresponding Contact Header reply.
> >    Only upon response of a Contact Header from the passive entity is the
> >    TCPCL protocol version established and parameter negotiation begun.
> >
> > Is this on the same TCP connection or successive new ones?  (The next
> > paragraph implies the same one, but it would be good to be explicit
> > about this.)
> >
> BS: Clarified by rephrasing that paragraph with the following requirement to
> close the TCP connection:
>
> If the active entity receives a Contact Header with a lower
> protocol version than the one sent earlier on the TCP connection,
> the TCP connection SHALL be closed.
> If the active entity receives a SESS_TERM message with reason of
> "Version Mismatch", that node MAY attempt further TCPCL sessions with the
> peer using earlier protocol version numbers in decreasing order.
> Managing multi-TCPCL-session state such as this is an implementation matter.

Thanks!  (I realized later on that since the Contact Header is a different
length for different versions, getting the framing right could be hard if
they were on the same TCP connection.)

> > Section 4.4
> >
> >    session to non-TLS operation.  If this is desired, the entire TCPCL
> >    session MUST be terminated and a new non-TLS-negotiated session
> >    established.
> >
> > Absent some reason why this might be desired, I don't think we need to
> > have this last sentence.
> >
> BS: Agreed. Removed this statement from an earlier comment.
>
> >    Once established, the lifetime of a TLS session SHALL be bound to the
> >    lifetime of the underlying TCP connection.  Immediately prior to
> >
> > As the secdir reviewer notes, "TLS session" is an existing term of art
> > for TLS-related state that can be persisted across underlying TCP
> > connections by means of "resumption".  Given my current understanding of
> > TCPCL (possibly flawed), I suggest avoiding the phrase and sticking with
> > the current TCPCL session semantics that are bound to the TCP
> > connection.
> >
> BS: I replaced most uses of "TLS session" with "TLS connection" to be consistent
> with TLS.
>
> >    actively ending a TLS session after TCPCL session termination, the
> >    peer which sent the original (non-reply) SESS_TERM message SHOULD
> >    follow the Closure Alert procedure of [RFC5246] to cleanly terminate
> >    the TLS session.  Because each TCPCL message is either fixed-length
> >
> > RFC 8446 is the current reference
> > (
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8446%23section-6.1&amp;data=02%7C01%7CBSipos%40rkf-eng.com%7C90f578c09ad54fcf7dc708d865acec81%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637371140684000399&amp;sdata=fhx6cb8Ga3CKfXh1HKbe9%2FMq7wDEnrO2tFRTclcrdeI%3D&amp;reserved=0
> > ).
> >
> BS: From earlier comment the new baseline TLS is 1.3 and all references to RFC
> 5246 are removed.
>
> > Section 4.4.1
> >
> >    session entities SHALL begin a TLS handshake in accordance with TLS
> >    1.2 [RFC5246] or any successors that are compatible with TLS 1.2.  By
> >
> > I think we can just say "begin a TLS handshake", citing RFC 8446, drop
> > the "in accordance with..." text, and say that version 1.2 or higher
> > MUST be negotiated.
> >
> BS: This was simplified after moving to TLS 1.3 baseline.
>
> >    convention, this protocol uses the node which initiated the
> >    underlying TCP connection as the "client" role of the TLS handshake
> >    request.
> >
> > That is to say, the "active" endpoint is the TLS client?
> >
> BS: Yes
>
> >    Server Certificate:  The passive entity SHALL supply a certificate
> >       within the TLS handshake to allow authentication of its side of
> >       the session.  When assigned a stable host name or address, the
> >       passive entity certificate SHOULD contain a subjectAltName entry
> >       which authenticates that host name or address.  The passive entity
> >
> > The current best practice is to reference RFC 6125 and talk about the
> > "DNS-ID" of the certificate.
> >
> BS: I'm adding an explicit reference and use of DNS-ID from RFC 6125 and adding
> a similar definition of a certificate "NODE-ID" to allow similar validation
> statements.
>
> >       certificate SHOULD contain a subjectAltName entry of type
> >       uniformResourceIdentifier which authenticates the Node ID of the
> >
> > Is this "SHOULD" a "MUST (unless using opportunistic TLS)"?  I might
> > suggest a different phrasing if so.
> >
> BS: I refactored the certificate identity informative and requirement statements
> to clarify the priority of what to identify and authenticate. Hopefully this
> addresses the next few comments.

(I think we're going to end up lumping all these comments in with the text
churn for the Discuss point, so won't comment further here.)

> >       peer.  The passive entity MAY use the SNI host name to choose an
> >       appropriate server-side certificate which authenticates that host
> >       name and corresponding Node ID.
> >
> > I'm not sure on how often there will be a unique "corresponding Node ID"
> > for a given hostname.  This seems like a new requirement that might be
> > worth documenting in a management considerations section.
> >
> BS: see above
>
> >    Client Certificate:  The active entity SHALL supply a certificate
> >
> > [ditto about RFC 6125, even though technically it only claims to apply
> > to server certificates -- since the situation here is symmetric, I think
> > it's okay to reuse the terminology.]
> >
> BS: see above
>
> >    All certificates supplied during TLS handshake SHALL conform with the
> >    profile of [RFC5280], or any updates or successors to that profile.
> >
> > nit: "profile of [RFC5280]" sounds like it's RFC 5280 that's being
> > profiled, not that RFC 5280 is itself a profile of X.509.  So, I'd say
> > either just "conform with [RFC5280]" or "confirm with the X.509 profile
> > of [RFC5280]".  (Well, I'd probably s/conform with/conform to/, too...)
> >
> BS: I rephrased this to be the short version.
>
> >    When a certificate is supplied during TLS handshake, the full
> >    certification chain SHOULD be included unless security policy
> >    indicates that is unnecessary.
> >
> > Is this intended to say that the root (trust anchor) certificate should
> > also be sent, even when the peer is assumed to already have a copy?
> > (This is not typical in TLS usage in other scenarios.)
> >
> BS: Yes, providing the full chain is the most interoperable in situations with
> multi-level CA hierarchies.
>
> >    If a TLS handshake cannot negotiate a TLS session, both entities of
> >    the TCPCL session SHALL close the TCP connection.  At this point the
> >    TCPCL session has not yet been established so there is no TCPCL
> >    session to terminate.  This also avoids any potential security issues
> >    assoicated with further TCP communication with an untrusted peer.
> >
> > I'm not entirely sure what's intended by "potential security issues"
> > here -- how is this different from any other TCP connection not using
> > TLS?
> >
> BS: I agree that statement does not add value and removed it.
>
> > Section 4.4.2
> >
> > The procedure that we describe here has a fairly convoluted description
> > and may be a little hard to follow (roughly, it seems to be "try really
> > hard to validate Node ID, and try somewhat less hard to validate
> > hostname/IP, but if you can do the former but not the latter it's still
> > okay").  It might be worth restructuring to have something of a
> > prioritized list/procedure, along the lines of "attempt to validate the
> > Node ID; if that succeeds, you're done and all is good.  If all fields
> > for validation is present but validation still fails, abort.  Otherwise
> > (not all fields for Node-ID validation are present), if policy allows,
> > validate the hostname (possibly limited to some set known from
> > out-of-band information to be "trusted" to a higher extent than just
> > having a certificate might indicate).  Fallback to opportunistic TLS can
> > be allowed by local policy."
> >
> BS: The sequential issue is that the Node ID isn't available to authenticate

Don't you know what node you're trying to contact, though (even if you
don't get the SESS_INIT until after the handshake)?

> until after the TLS handshake is completed so the requirements are:
> 1. Collect what exactly has been authenticated about the entity.
> 2. Apply policy to what was authenticated, but the spec really cannot say what
> concrete policy should apply to an arbitrary network.

(This seems to be getting into the same topic as the Discuss point, so I'll
not say more in this location.)

> >    Using X.509 certificates exchanged during the TLS handshake, each of
> >    the entities can attempt to authenticate its peer at the network
> >    layer (host name and address) and at the application layer (BP Node
> >    ID).  The Node ID exchanged in the Session Initialization is likely
> >
> > I think it's perhaps subjective or controversial to say that the network
> > address is authenticated by the X.509 validation process (barring
> > iPAddress certificates) and would suggest just using "host name" if
> > there is no specific reason to also list address.
> >
> BS: I rephrased this to clarify and agree with the new earlier section on Entity
> Identification.
>
> >    By using the SNI host name (see Section 4.4.1) a single passive
> >    entity can act as a convergence layer for multiple BP agents with
> >    distinct Node IDs.  When this "virtual host" behavior is used, the
> >    host name is used as the indication of which BP Node the passive
> >    entity is attempting to communicate with.  A virtual host CL entity
> >
> > nit: either "communicate as" or "active entity is attempting".
> >
> BS: agreed and rephrased
>
> >    entity is attempting to communicate with.  A virtual host CL entity
> >    can be authenticated by a certificate containing all of the host
> >    names and/or Node IDs being hosted or by several certificates each
> >    authenticating a single host name and/or Node ID.
> >
> > I suggest to append ", using the SNI value from the client to select
> > which certificate to use".
> >
> BS: agreed and rephrased
>
> >    of the TCP connection.  The passive entity SHALL attempt to
> >    authenticate the IP address of the other side of the TCP connection.
> >    The passive entity MAY use the IP address to resolve one or more host
> >    names of the active entity and attempt to authenticate those.  If
> >
> > Er, is this saying that we basically expect everyone to have IP-address
> > certificates?
> > Also, using reverse DNS like this is pretty risky security posture in
> > the absence of DNSSEC on the reverse zone.
> >
> BS: This requirement is to attempt the authentication, but not to require that
> it succeed. I did remove the reverse-lookup as that does represent an
> unnecessary risk.
>
> > I might note in the caption for Figure 17 that the closure procedures
> > can be initiated by either entity.
> >
> BS: Added a statement to clarify this.
>
> > Section 4.5
> >
> >    | SESS_TERM    | 0x05 |              Indicates that one of the      |
> >    |              |      | entities participating in the session       |
> >    |              |      | wishes to cleanly terminate the session, as |
> >    |              |      | described in             Section 6.         |
> >
> > Is section 6.1 a better reference?
> >
> BS: Yes, updated reference.
>
> > Section 4.6
> >
> >    Keepalive Interval:  A 16-bit unsigned integer indicating the
> >       interval, in seconds, between any subsequent messages being
> >       transmitted by the peer.  The peer receiving this contact header
> >       uses this interval to determine how long to wait after any last-
> >       message transmission and a necessary subsequent KEEPALIVE message
> >       transmission.
> >
> > It might be worth giving more clarity as to whether this is an
> > indication of "this is what I will do" vs. "this is what you should do
> > when talking to me".
> >
> BS: For better or worse, TCPCLv4 inherits the v3 KEEPALIVE behavior.
> I removed the statements and added a reference to the Session Negotiation
> section 4.7.
>
> >    Node ID Length and Node ID Data:  Together these fields represent a
> >       [...]
> >       message.  Every Node ID SHALL be a URI consistent with the
> >       requirements of [RFC3986] and the URI schemes of
> >       [I-D.ietf-dtn-bpbis].  The Node ID itself can be authenticated as
> >
> > It may be better to refer to the "Bundle Protocol URI scheme types"
> > registry established by bpbis than the hardcoded list of URI schemes
> > contained within bpbis.
> >
> BS: I updated both the certificate URI and this requirement to refer to the new
> IANA registry.
>
> > Section 4.7
> >
> >    An entity calculates the parameters for a TCPCL session by
> >    negotiating the values from its own preferences (conveyed by the
> >    contact header it sent to the peer) with the preferences of the peer
> >    node (expressed in the contact header that it received from the
> >    peer).  The negotiated parameters defined by this specification are
> >
> > Aren't these from the SESS_INIT message rather than the contact header?
> >
> BS: Yes, corrected these typos.
>
> >    Session Keepalive:  Negotiation of the Session Keepalive parameter is
> >       performed by taking the minimum of this two contact headers'
> >       Keepalive Interval.  The Session Keepalive interval is a parameter
> >       for the behavior described in Section 5.1.1.  If the Session
> >       Keepalive interval is unacceptable, the node SHALL terminate the
> >       session with a reason code of "Contact Failure".
> >
> > It's probably worth mentioning that a value of zero means "keepalives
> > are disabled".  The procedure given here does seem consistent with the
> > discussion in Section 5.1.1 that indicates that either peer can
> > unilaterally disable keepalives (as opposed to the behavior one might
> > naively expect by having the encoded value zero reflect an effective
> > interval of "infinity").
> >
> BS: Yes, I've added a clarifying note. This is inherited from TCPCLv3 behavior.
>
> > Section 4.8
> >
> >    Item Type:  A 16-bit unsigned integer field containing the type of
> >       the extension item.  This specification does not define any
> >       extension types directly, but does allocate an IANA registry for
> >       such codes (see Section 9.3).
> >
> > nit: I think we typically say that we "allocate" codepoints from
> > registries but "create" registries themselves.
> >
> BS: Fixed this phrasing
>
> >    choose a keepalive interval no shorter than 30 seconds.  There is no
> >    logical maximum value for the keepalive interval, but an idle TCP
> >
> > It's a fixed-width field; there's a maximum.
> >
> BS: Added clarifying note.
>
> >    Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP
> >    retransmissions MAY occur in case of packet loss.  Those will have to
> >    be triggered by a timeout (TCP retransmission timeout (RTO)), which
> >    is dependent on the measured RTT for the TCP connection so that
> >    KEEPALIVE messages MAY experience noticeable latency.
> >
> > nit: s/MAY/may/; this statement is describing a property of TCP and not
> > granting implementations permission to engage in a particular behavior.
> >
> BS: Fixed this phrasing from an earlier comment.
>
> > Section 5.2.1
> >
> >    Each transfer entails the sending of a sequence of some number of
> >    XFER_SEGMENT and XFER_ACK messages; all are correlated by the same
> >    Transfer ID.
> >
> >    Transfer IDs from each node SHALL be unique within a single TCPCL
> >    session.  The initial Transfer ID from each node SHALL have value
> >    zero.  Subsequent Transfer ID values SHALL be incremented from the
> >    prior Transfer ID value by one.  Upon exhaustion of the entire 64-bit
> >    Transfer ID space, the sending node SHALL terminate the session with
> >    SESS_TERM reason code "Resource Exhaustion".
> >
> > I'd suggest adding some discussion that the sender of the XFER_SEGMENTs
> > allocates the Transfer ID and the XFER_ACKs respond to it; the current
> > text is potentially confusing since the ID in an XFER_ACK could be
> > considered to be a "transfer ID from [each] node" but is really in the
> > peer node's namespace.
> >
> > Also, it's not entirely clear that there's a need for predictable IDs
> > starting from zero;
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gont-numeric-ids-sec-considerations-04&amp;data=02%7C01%7CBSipos%40rkf-eng.com%7C90f578c09ad54fcf7dc708d865acec81%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637371140684000399&amp;sdata=OrEEF0uuuAz86QmrwsJtJcc4PwKZbAMz9D8JhxLQNPQ%3D&amp;reserved=0
> >
> > has some further discussion about potential pitfalls of such predictable
> > identifiers.
> >
> BS: I added a clarifying statement about actual required behavior, changed the
> trivial generation algorithm to a qualified requirement, and added a Security
> subsection discussing Predictable Transfer IDs.

Thanks for thinking through and writing up the security considerations.

> > Section 5.2.2
> >
> >    The flags portion of the message contains two optional values in the
> >    two low-order bits, denoted 'START' and 'END' in Table 5.  The
> >
> > I'm always a little wary of using "optional" for situations like these,
> > since "optional" can imply that they appear subject to the whims of the
> > implementation/higher-layer, but when they do/don't appear here is
> > actually tightly constrained by the protocol specification.  Perhaps
> > it's better to talk of information being conveyed by the value of these
> > bits than them containing optional values.
> >
> BS: I rephrased this from "optional values" to "flag values".
>
> > Section 5.2.3
> >
> >    A receiving TCPCL node SHALL send an XFER_ACK message in response to
> >    each received XFER_SEGMENT message.  The flags portion of the
> >    XFER_ACK header SHALL be set to match the corresponding DATA_SEGMENT
> >    message being acknowledged.  The acknowledged length of each XFER_ACK
> >
> > I don't think there is a DATA_SEGMENT (vs. XFER_SEGMENT) message
> > defined.
> >
> > Also, is the receiver expected to echo flags from the XFER_SEGMENT that
> > it does not comprehend?
> >
> BS: I corrected the DATA_SEGMENT typo and clarified that the echo is the entire
> bitfield including undecodable flags.
>
> > Section 5.2.4
> >
> >    | Extension  | 0x01 | A failure processing the Transfer Extension   |
> >    | Failure    |      | Items ha occurred.                            |
> >
> > nit: "has"
> >
> BS: Fixed this
>
> >    Note: If a bundle transmission is aborted in this way, the receiver
> >    MAY not receive a segment with the 'END' flag set to 1 for the
> >    aborted bundle.  The beginning of the next bundle is identified by
> >
> > nit: I think "might not" is more appropriate here, as this is describing
> > expectations and not some active choice the receiver can make.
> >
> BS: Removed the requirement text here.
>
> > Section 5.2.5.1
> >
> >    Total Length:  A 64-bit unsigned integer indicating the size of the
> >       data-to-be-transferred.  The Total Length field SHALL be treated
> >       as authoritative by the receiver.  If, for whatever reason, the
> >       actual total length of bundle data received differs from the value
> >       indicated by the Total Length value, the receiver SHALL treat the
> >       transmitted data as invalid.
> >
> > It seems like this might be setting things up for information skew
> > between endpoints, where the receiver has discarded a bundle but the
> > sender thinks it was successfully transmitted.  Would it make sense to
> > require an XFER_REFUSE in such a case?
> >
> BS: It does make sense, and this brings up the issue that there is no
> XFER_REFUSE reason code Not Acceptable for "didn't like the transfer data".
>
> > Section 6.1
> >
> >    Instead of following a clean shutdown sequence, after transmitting a
> >    SESS_TERM message an entity MAY immediately close the associated TCP
> >    connection.  When performing an unclean shutdown, a receiving node
> >    SHOULD acknowledge all received data segments before closing the TCP
> >    connection.  Not acknowledging received segments can result in
> >    unnecessary retransmission.  When performing an unclean shutodwn, a
> >
> > I'm not sure I understand the nature of this indicated "unnecessary
> > retransmission".  My first thought was that there would be a way to
> > reestablish a new session between the same endpoints and reuse the
> > Transaction ID to "start in the middle" of the bundle, but I don't see
> > any mechanisms designed to allow that or to assign semantics to
> > transaction IDs across sessions.  So the only thing I can come up with
> > would be ordinary TCP-layer retransmissions, but those are within the
> > TCP stack's abstraction boundary, so I'm not sure if it makes sense to
> > talk about them.
> >
> BS: The phrasing here changed slightly from an earlier comment, but the
> "unnecessary retransmission" is changed to "unnecessary bundle or bundle
> fragment retransmission". You are correct that the TCPCL doesn't preserve any
> state between sessions and there is no such way to resume a transmission. BP can
> potentially use a technique called "reactive fragmentation" to deal with such a
> situation, but this occurs at the BP agent level not the TCPCL entity level.
> The whole purpose of the Ending state is to avoid closing a TCP connection when
> a transfer is 90% completed and the whole transfer was for nothing. It allows
> closing the TCP connection at the next opportune moment.
>
> A potential future SESS_INIT extension could enable such a transfer resumption
> mechanism, but the current spec doesn't cover this.

Thanks for the additional explanation; I feel like I have a better handle
on this now.

> >    | Contact      | 0x04 | The node cannot interpret or negotiate      |
> >    | Failure      |      | contact header option.                      |
> >
> > nit: I think there's a singular/plural mismatch here.
> >
> BS: This is rephrased to read "... a contact header or SESS_INIT option."
>
> >    connection without sending a SESS_TERM message.  If the content of
> >    the Session Extension Items data disagrees with the Session Extension
> >    Length (i.e. the last Item claims to use more octets than are present
> >    in the Session Extension Length), the reception of the contact header
> >    is considered to have failed.
> >
> > nit: is it reception of the contact header or the SESS_INIT that is to
> > have failed?
> >
> BS: This is a typo, it is the SESS_INIT which has failed.
>
> > Section 8
> >
> > Thanks for the throrough security considerations; I really appreciate
> > the work that went into the discussion with the secdir reviewer.
> >
> > Section 8.2
> >
> > I think this text implies that a malicious or compromised node can view
> > bundle contents (which to some extent is a consideration for the core
> > bundle protocol and not the convergence layer anyway), so it's probably
> > okay to leave it as-is.
> >
> BS: Yes, this is just a reiteration that TCPCL/TLS is good for authentication
> and OPSEC but end-to-end security demands BPSEC use.
>
> > Section 8.3
> >
> > I suggest noting that an active on-path attacker can also cause use of
> > an older/different TCPCL version.
> >
> BS: I added a statement for this.
>
> >    of TCPCL which does not support transport security.  It is up to
> >    security policies within each TCPCL node to ensure that the TCPCL
> >    version in use meets transport security requirements.
> >
> > I'm not sure whether it's worth noting this in the document, but a
> > consequence of this is that if the security policy allows more than one
> > TCPCL version, the on-path attacker has control over which of those
> > versions gets used, even if that protocol itself nominally operats in a
> > secure fashion.
> >
> BS: the earlier edit does mention the downgrade
>
> > Section 8.4
> >
> >    The purpose of the CAN_TLS flag is to allow the use of TCPCL on
> >    entities which simply do not have a TLS implementation available.
> >    When TLS is available on an entity, it is strongly encouraged that
> >    the security policy disallow non-TLS sessions.  This requires that
> >
> > Is it only "strongly encouraged" or a "SHALL-level requirement" (per
> > Section 4.2)?
> >
> BS: Per WG agreement, it is a valid situation to use non-TLS TCPCL so it's not a
> real SHALL requirement to set this policy.
>
> > Section 8.6
> >
> >    or using it after it has been revoked by its CA.  Validating a
> >    certificate is a complex task and may require network connectivity if
> >    a mechanism such as the Online Certificate Status Protocol (OCSP) is
> >    used by the CA.  The configuration and use of particular certificate
> >
> > nit: I suggest "external network connectivity"; some level of network
> > connectivity has to be present in order for TCPCL to be used at all...
> >
> BS: rephrased this to:
> network connectivity outside of the primary TCPCL network path(s)
>
> > Section 8.7
> >
> >    When permitted by the negotiated TLS version (see [RFC8446]), it is
> >    advisable to take advantage of session key updates to avoid those
> >    limits.  When key updates are not possible, establishing new TCPCL/
> >    TLS session is an alternative to limit session key use.
> >
> > This is not necessarily a question that needs to be answered in the RFC,
> > but do you consider TLS 1.2 renegotiation to be a "session key update
> > mechanism"?
> >
> BS: I did add some clarification that a renegotiation which updates keys will
> avoid this issue.

But we don't allow TLS 1.2 anymore, so I think we have to revert that
change.  Sorry for the extra churn!

Thank you for all the updates, and my apologies again for the slow
response.

-Ben

> > Section 8.8
> >
> >    certificates can be guaranteed to validate the peer's Node ID.  In
> >    circumstances where certificates can only be issued to network host
> >    names, Node ID validation is not possible but it could be reasonable
> >    to assume that a trusted host is not going to present an invalid Node
> >    ID.
> >
> > I think we should also say that determination of whether a given host is
> > trusted in this fashion is out of scope for this document (since it's a
> > very important consideration but we cannot give universal guidance on
> > it).
> >
> BS: I agree and have added such a statement.
>
> > Section 8.9
> >
> > TCP RST injection is also a DoS vector (potentially from off-path), as
> > boring as it is...
> >
> BS: Agreed and added a final paragraph
>
> > Section 8.10
> >
> >
> >    This specification makes use of public key infrastructure (PKI)
> >    certificate validation and authentication within TLS.  There are
> >    alternate uses of TLS which are not necessarily incompatible with the
> >    security goals of this specification, but are outside of the scope of
> >    this document.
> >
> > There are other PKIs than X.509 PKIs, so I'd suggest "X.509 public key
> > infrastructure".
> >
> > Also, I think it would be reasonable to give some examples of other
> > modes of using TLS ("e.g., non-X.509 certificates or raw public keys")
> > if you want.
> >
> BS: Rephrased these statements.
>
> > Section 9
> >
> > Should we make registries for the various flag words (vs. requiring an
> > RFC updating this one in order to allocate new values)?
> >
> BS: I don't feel strongly about this, but with the use of extension items in
> this protocol I don't see where new flag values would be helpful.
>
> > Section 9.1
> >
> > The IESG should perhaps talk (again) about updating the port
> > registration made by an IRTF-stream document.
> >
> BS: I'll defer to the AD about this, but my understanding is that the IRTF has
> been notified and has pre-approved this action.
>
> > Section 11.2
> >
> > One could perhaps argue that [AEAD-LIMITS] is more properly normative,
> > but I don't feel very strongly about it.
> >
> BS: I don't feel strongly either, but this reference is about a vulnerability
> and not a protocol behavior.
>
>
>