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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 1 Jun 2020 13:53:00 +0000

Hi,

I would appreciate the SEC ADs input on this. 

I think you are correct that PKI structure and how to validate IPN and DTN URI
in regards to the certificats are seperate document. 

So don't we have two different aspects here for TCPCLv4. One when it is used as
CL to reach a next hop in the routing infrastructure, where the sending agent
only need to know that it connected to the intended next hop. The other case is
when the agent uses the CL to directly reach the peer agent with the intended BP
layer destination Node ID. Maybe I have focused to much on the later and it is
only the former that actually are needed here. Still BP routers do have their
own Node ID and thus, I guess the identification dilema for Node IDs do remain. 

However, I think TCPCLv4 needs to be very clear what security determination can
be made currently, and what can't be done. The hierarchical domain names may be
sufficient if one have a mapping database between node ID and domain names that
one actually can trust. 

So how can we separate things here to enable things do be done in stages.
Becasue to me the whole aspect of doing due dilegence on a Node ID in a SAN is
not possible until there exist an addressing specification for how a BP endpoint
gets its address and can prove its right to that address. 

Cheers

Magnus

On Fri, 2020-05-29 at 13:31 +0000, Brian Sipos wrote:
> Magnus,
> From my perspective, when a certificate which has one or more Subject Alt Name
> (SAN) entries each of those entries is an independent claim binding the holder
> of the certificate to the associated name. There are not any cross-
> relationships between individual SAN in the same cert. Validating the
> certificate by a peer then authenticates the associated SAN claims.
> 
> Because of this, it is the duty of the PKI CA to perform due diligence when
> issuing *any* SAN. There is requirement for this in RFC 5280 [1] Section
> 4.2.1.6:
> > Because the subject alternative name is considered to be definitively
> > bound to the public key, all parts of the subject alternative name
> > MUST be verified by the CA.
> 
> This is not unique to TCPCL use in any way. The way a CA verifies ownership of
> a DTN URI is different from the "normal" ways that a CA can verify ownership
> of a DNS domain. RFC 5280 gives no guidance for how a CA goes about verifying
> DNS names, and while RFC 6125 [2] has guidance for "clients" of a certificate
> to authenticate SANs it also doesn't give guidance for CAs issuing
> certificates with SANs. The nearest I can find is a description of current
> practices in RFC 8555 [3] Section 1 but these are descriptive and not
> normative.
> 
> All that being said, I feel that recommendations to CAs for what kind of
> techniques or mechansisms should be used to verify DTN URIs belongs in a
> separate BCP-type document. I can think of a couple of similar "prove you own
> this DTN URI" techniques but these would certainly need further WG discussion.
> Also these techniques would not themselves be specific to TCPCL, they would
> apply to any CA issuing URI SANs for a DTN.
> 
> Please let me know if any of this seems unreasonable in the context of the
> current TCPCL draft.
> Thank you,
> Brian S.
> 
> [1] https://tools.ietf.org/html/rfc5280
> [2] https://tools.ietf.org/html/rfc6125
> [3] https://tools.ietf.org/html/rfc8555
> 
>  From: Magnus Westerlund
> Sent: Wednesday, May 27, 2020 09:37
> To: Brian Sipos; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with
> DISCUSS and COMMENT)
> 
> Hi Ben,
> 
> I would appreciate if you did take a look at the updated version that has 
> significant changes in regards to the TLS interactions and description of 
> those.
> 
> https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/
> 
> However, I like to discuss with you and the WG if we have a serious issue in 
> these rules, and which makes the server certificate worth very little.
> 
> The issue I see is that for normal Web PKI if a browser opens a connection
> for 
> alice.foo.com and gets a cert that says foo.com and has a AltSubjectName: 
> alice.foo.com it will be fine. However, if I put in alice.bar.com which is
> not 
> a subdomain of the primary name in the cert it will reject the altSubjectName.
> 
> However, here for TCPclv4. We basically have the issue that the server cert 
> will look like this.
> Primary name: alice.foo.com
> AltSubjecName: dtn:12345678A
> 
> How does the TLS client evaluate that alice.foo.com has the authority over 
> nodeID 1234567A? How does the CA do this? I guess this is part of the core of 
> your discuss about how does the PKI for DTN look like. I think we have a 
> significant issue with how one prevents an attacker from claiming that it has 
> a particular NodeID.
> 
> Cheers
> 
> Magnus
> 
> > -----Original Message-----
> > From: dtn <[email-masked]> On Behalf Of Brian Sipos
> > Sent: den 6 mars 2020 06:11
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18:
> > (with DISCUSS and COMMENT)
> >
> > 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://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/
> > >
> > >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > 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.
> >
> > > 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.
> >
> > > 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.
> >
> > > 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.
> >
> > >
> > > ----------------------------------------------------------------------
> > > 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.
> >
> > >    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.
> >
> > > 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".
> >
> > >    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.
> >
> > > 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    | | |
> > | | +-----------------+   |  |              |  | +-----------------+ | |
> > | +-----------------------+  |              |  +---------------------+ |
> > +----------------------------+              +--------------------------+
> >
> > > 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://tools.ietf.org/html/rfc8446#section-9.3
> > >
> > > (though presumably less complicated!), since we are changing how
> > > things work between TCPCLv3 and TCPCLv4.
> > >
> > BS:
> >
> > >    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?
> >
> > > 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..
> >
> > > 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://tools.ietf.org/html/rfc8446#section-6.1
> > > ).
> > >
> > 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.
> >
> > >       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
> > 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.
> >
> > >    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://tools.ietf.org/html/draft-gont-numeric-ids-sec-considerations-
> > > 04
> > >
> > > 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.
> >
> > > 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.
> >
> > >    | 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.
> >
> > > 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.
> >
> >
> 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Brian Sipos <[email-masked]>
Date: Mon, 1 Jun 2020 16:57:03 +0000

Magnus,
To clarify two distinct use cases for TCPCL security:

  1.  On a private network, with private PKI and control of a CA:
In this situation I see it more as the CA's obligation to coordinate with the network designer so that when a new BP Node is allocated that it gets proper BP configuration, TCPCL configuration, and a TLS certificate (to authenticate the Node ID URI) is produced. The validation of its identity and private key occurs via side channels the same way the Node is otherwise managed and configured.
  2.  On a more open network, where some other organization controls PKI roots and signing CAs:
In the near term, public CAs only know how to validate DNS names and are likely only willing to sign certificates with DNS name SANs. In this case the CA doesn't know or care about the Node ID and any BP Node which authorizes transfers to/from a TCPCL entity with a DNS-only authentication just has to have an implicit trust that an authenticated DNS name will not falsely claim a Node ID. This risk is identified in Section 8.8 "Threat: BP Node Impersonation" [1] and a BP Node can choose accept this risk as a policy decision.

I think both of these situations are reasonable if BP is used to traverse an open network where some of the intermediate nodes are not fully trusted. Like you said, it would be possible for the configuration of a node to have a specific whitelist of which public hosts are trusted to forward bundles. And maybe the node policy can be nuanced as you have stated so that if a node is the bundle destination it *must* have a TLS-authenticated Node ID. In the end, the whole point of CL-level security is to ensure that data/bundles are not being leaked in the clear on a single hop. You still need to use BPSEC if the intent is to guaruantee integrity or authenticity of the bundle itself.

Because ACME [2] provides a solid infrastructure to separate the mechanisms of how to challenge and validate a claim from what to do with the validated claims (i.e. issue a requested certificate), if it seems reasonable I am willing to create a draft of a new ACME challenge type for validating a DTN Node ID using a new BP administrative record type. This challenge type would be extremely logically simple and could be done on its own, outside of an ACME server, to validate ownership of a Node ID in a more "manual" way. Doing this gives us something more concrete than a BCP explaining a procedure.

[1] https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-20#section-8.8
[2] https://tools.ietf.org/html/rfc8555#section-8

________________________________
From: Magnus Westerlund <[email-masked]>
Sent: Monday, June 1, 2020 09:53
To: [email-masked] <[email-masked]>; Brian Sipos <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

Hi,

Cheers

Magnus

--
Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 2 Jun 2020 12:58:43 +0000

Thanks Brian,

I think what you write below are quite clear. And I think has reasonable
security policies and a particular set of properties. However, I don't think
either Section 4.4 or the Security Consideration goes into these. They
support these but appear to have more fluid boundaries to even more
policies. So the question is if the specification should be more articulate
about these two targets and state that additional security policies with
associated properties can be defined later either in implementation or
future documents. 

Cheers

Magnus

From: Brian Sipos <[email-masked]> 
Sent: den 1 juni 2020 18:57
To: Magnus Westerlund <[email-masked]>; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with
DISCUSS and COMMENT)

Magnus,

1.	On a private network, with private PKI and control of a CA:
In this situation I see it more as the CA's obligation to coordinate with
the network designer so that when a new BP Node is allocated that it gets
proper BP configuration, TCPCL configuration, and a TLS certificate (to
authenticate the Node ID URI) is produced. The validation of its identity
and private key occurs via side channels the same way the Node is otherwise
managed and configured.
2.	On a more open network, where some other organization controls PKI
roots and signing CAs:
In the near term, public CAs only know how to validate DNS names and are
likely only willing to sign certificates with DNS name SANs. In this case
the CA doesn't know or care about the Node ID and any BP Node which
authorizes transfers to/from a TCPCL entity with a DNS-only authentication
just has to have an implicit trust that an authenticated DNS name will not
falsely claim a Node ID. This risk is identified in Section 8.8 "Threat: BP
Node Impersonation" [1] and a BP Node can choose accept this risk as a
policy decision.

I think both of these situations are reasonable if BP is used to traverse an
open network where some of the intermediate nodes are not fully trusted.
Like you said, it would be possible for the configuration of a node to have
a specific whitelist of which public hosts are trusted to forward bundles.
And maybe the node policy can be nuanced as you have stated so that if a
node is the bundle destination it *must* have a TLS-authenticated Node ID.
In the end, the whole point of CL-level security is to ensure that
data/bundles are not being leaked in the clear on a single hop. You still
need to use BPSEC if the intent is to guaruantee integrity or authenticity
of the bundle itself.

Because ACME [2] provides a solid infrastructure to separate the mechanisms
of how to challenge and validate a claim from what to do with the validated
claims (i.e. issue a requested certificate), if it seems reasonable I am
willing to create a draft of a new ACME challenge type for validating a DTN
Node ID using a new BP administrative record type. This challenge type would
be extremely logically simple and could be done on its own, outside of an
ACME server, to validate ownership of a Node ID in a more "manual" way.
Doing this gives us something more concrete than a BCP explaining a
procedure.

  _____  

From: Magnus Westerlund <[email-masked]
<mailto:[email-masked]> >
Sent: Monday, June 1, 2020 09:53
To: [email-masked] <mailto:[email-masked]>  <[email-masked]
<mailto:[email-masked]> >; Brian Sipos <[email-masked]
<mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]>  <[email-masked]
<mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]>  <[email-masked]
<mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]>  <[email-masked]
<mailto:[email-masked]> >
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with
DISCUSS and COMMENT) 

Hi,

I think you are correct that PKI structure and how to validate IPN and DTN
URI
in regards to the certificats are seperate document. 

So don't we have two different aspects here for TCPCLv4. One when it is used
as
CL to reach a next hop in the routing infrastructure, where the sending
agent
only need to know that it connected to the intended next hop. The other case
is
when the agent uses the CL to directly reach the peer agent with the
intended BP
layer destination Node ID. Maybe I have focused to much on the later and it
is
only the former that actually are needed here. Still BP routers do have
their
own Node ID and thus, I guess the identification dilema for Node IDs do
remain. 

However, I think TCPCLv4 needs to be very clear what security determination
can
be made currently, and what can't be done. The hierarchical domain names may
be
sufficient if one have a mapping database between node ID and domain names
that
one actually can trust. 

So how can we separate things here to enable things do be done in stages.
Becasue to me the whole aspect of doing due dilegence on a Node ID in a SAN
is
not possible until there exist an addressing specification for how a BP
endpoint
gets its address and can prove its right to that address. 

Cheers

Magnus

On Fri, 2020-05-29 at 13:31 +0000, Brian Sipos wrote:
> To: Brian Sipos; [email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
> Cc: [email-masked]
<mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; 
> [email-masked] <mailto:[email-masked]> 

> > From: dtn <[email-masked] <mailto:[email-masked]> > On
Behalf Of Brian Sipos
> > To: [email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
> > Cc: [email-masked]
<mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ;
> > [email-masked] <mailto:[email-masked]> 

-- 
Cheers

Magnus Westerlund

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 5 Jun 2020 11:00:10 -0700

Hi Magnus, Brian,

Sorry for the slow response here -- I've been trying to meet a deadline at
work and email responses have suffered.

I think Brian's discussion and explanations in this thread are generally
spot-on.  I'll make a few notes inline but they don't really touch on the
core substance of things.

I do wonder, though (Magnus), why you are under the impression that (as
stated in the start of the thread) " for normal Web PKI if a browser opens
a connection for alice.foo.com and gets a cert that says foo.com and has a
AltSubjectName: alice.foo.com it will be fine. However, if I put in
alice.bar.com which is not a subdomain of the primary name in the cert it
will reject the altSubjectName."  My understanding matches Brian's that all
SANs and the CN are treated independently (and in particular, that if SANs
exist, they are generally preferred over CN).

[more inline]

> associated properties can be defined later either in implementation or

I still have an action item to read the updated I-D, and will try to keep
this topic in mind as I do so.

> likely only willing to sign certificates with DNS name SANs. In this case

I don't think this is quite true, depending on how you define "public CAs".
There's a very long thread (including, unfortunately, a lot of redundant
bits where people are talking past each other) on a similar topic, what it
means to be a "public CA", and what "public CAs" currently can and are
(not) willing to do, in the thread at
https://mailarchive.ietf.org/arch/msg/emu/8G6q7TnhgixgS92QWBNqL7vWd2U/

Key topics include the need for an agreed set of rules for CAs to operate
by in order for consuming applications to put trust in the certifications
coming out of the CAs.  That is, a sense that if the rules are followed,
then clients will get the properties they need by trusting the CA
signatures.  And, of course, enough people doing enforcement that CAs
actually follow the rules properly, to keep things working right.

We're thinking about potentially having a future SAAG talk about non-web
PKI topics (and if there's guidance we can/should give for starting such an
ecosystem).

> Doing this gives us something more concrete than a BCP explaining a

I am wary of describing this as "outside of an ACME server": the separate
account-provisioning step and cryptographic means to bind an intent to
authorize a given name by a given account to the actual challenge and
challenge-validation steps are important parts of achieving the properties
that ACME provides.

> own Node ID and thus, I guess the identification dilema for Node IDs do

(I think this dilemma is at the core of my uneasiness with the draft
originally proposed for IESG Evaluation.  It's not a problem that's fully
solvable, though, so we'll need to clearly document what we do/don't do and
move on, as was noted later in the thread.)

-Ben

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 8 Jun 2020 08:00:13 +0000

Hi Ben and Brian,

> exist, they are generally preferred over CN).

Yes, I guess I made an error in though here. So maybe the better question is
what type of runtime validation that is done related to domain names on the
certificate and its chain, any at all? Or is all this checking happening by the
enitity signing the certificate in the certificate chain? 

What appear clear is that we really should keep the basic checking required for
any TLS usage in TCPCLv4 document seperated from what would be required for any
type of PKI for the DTN or IPN namespaces. 

I think the immediate question here boils down to what are the aspect around
this that we need to note in the TCPCLv4 document? I do note that some of it is
inlide below. 

-- 
Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Jun 2020 11:55:52 +0000

Hi,

I think the new text on the CA looks reasonable as providing a context for
the certificate validation text. 

Ben, can you please check if the document resolves your discuss now? 

Cheers

Magnus Westerlund

> From: dtn <[email-masked]> On Behalf Of Magnus Westerlund
> Sent: den 8 juni 2020 10:00
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> > Sorry for the slow response here -- I've been trying to meet a
> > deadline at work and email responses have suffered.
> >
> > I think Brian's discussion and explanations in this thread are
> > generally spot-on.  I'll make a few notes inline but they don't really
> > touch on the core substance of things.
> >
> > I do wonder, though (Magnus), why you are under the impression that
> > (as stated in the start of the thread) " for normal Web PKI if a
> > browser opens a connection for alice.foo.com and gets a cert that says
> > foo.com and has a
> > alice.bar.com which is not a subdomain of the primary name in the cert
> > it will reject the altSubjectName."  My understanding matches Brian's
> > that all SANs and the CN are treated independently (and in particular,
> > that if SANs exist, they are generally preferred over CN).
> 
> What appear clear is that we really should keep the basic checking
required
> for any TLS usage in TCPCLv4 document seperated from what would be
> required for any type of PKI for the DTN or IPN namespaces.
> 
> I think the immediate question here boils down to what are the aspect
> around this that we need to note in the TCPCLv4 document? I do note that
> some of it is inlide below.
> 
> 
> >
> > [more inline]
> >
> > > I think what you write below are quite clear. And I think has
> > > reasonable security policies and a particular set of properties.
> > > However, I don't think either Section 4.4 or the Security
> > > Consideration goes into these. They support these but appear to have
> > > more fluid boundaries to even more policies. So the question is if
> > > the specification should be more articulate about these two targets
> > > and state that additional security policies with associated
> > > properties can be defined later either in implementation or future
> documents.
> >
> > I still have an action item to read the updated I-D, and will try to
> > keep this topic in mind as I do so.
> >
> > >
> > >
> > > Cheers
> > >
> > >
> > >
> > > Magnus
> > >
> > >
> > >
> > > To: Magnus Westerlund <[email-masked]>;
> > > [email-masked]; [email-masked]
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > In this situation I see it more as the CA's obligation to coordinate
> > > with the network designer so that when a new BP Node is allocated
> > > that it gets proper BP configuration, TCPCL configuration, and a TLS
> > > certificate (to authenticate the Node ID URI) is produced. The
> > > validation of its identity and private key occurs via side channels
> > > the same way the Node is otherwise managed and configured.
> > > In the near term, public CAs only know how to validate DNS names and
> > > are likely only willing to sign certificates with DNS name SANs. In
> > > this case
> >
> > There's a very long thread (including, unfortunately, a lot of
> > redundant bits where people are talking past each other) on a similar
> > topic, what it means to be a "public CA", and what "public CAs"
> > currently can and are
> > Key topics include the need for an agreed set of rules for CAs to
> > operate by in order for consuming applications to put trust in the
> > certifications coming out of the CAs.  That is, a sense that if the
> > rules are followed, then clients will get the properties they need by
> > trusting the CA signatures.  And, of course, enough people doing
> > enforcement that CAs actually follow the rules properly, to keep things
> working right.
> >
> > We're thinking about potentially having a future SAAG talk about
> > non-web PKI topics (and if there's guidance we can/should give for
> > starting such an ecosystem).
> >
> > > authorizes transfers to/from a TCPCL entity with a DNS-only
> > > authentication just has to have an implicit trust that an
> > > authenticated DNS name will not falsely claim a Node ID. This risk
> > > is identified in Section 8.8 "Threat: BP Node Impersonation" [1] and
> > > a BP Node can choose accept this risk as a policy decision.
> > >
> > > I think both of these situations are reasonable if BP is used to
> > > traverse an open network where some of the intermediate nodes are
> not fully trusted.
> > > Like you said, it would be possible for the configuration of a node
> > > to have a specific whitelist of which public hosts are trusted to
forward
> bundles.
> > > And maybe the node policy can be nuanced as you have stated so that
> > > if a node is the bundle destination it *must* have a TLS-authenticated
> Node ID.
> > > data/bundles are not being leaked in the clear on a single hop. You
> > > still need to use BPSEC if the intent is to guaruantee integrity or
> > > authenticity of the bundle itself.
> > >
> > >
> > >
> > > Because ACME [2] provides a solid infrastructure to separate the
> > > mechanisms of how to challenge and validate a claim from what to do
> > > with the validated claims (i.e. issue a requested certificate), if
> > > it seems reasonable I am willing to create a draft of a new ACME
> > > challenge type for validating a DTN Node ID using a new BP
> > > administrative record type. This challenge type would be extremely
> > > logically simple and could be done on its own, outside of an ACME
server,
> to validate ownership of a Node ID in a more "manual" way.
> > I am wary of describing this as "outside of an ACME server": the
> > separate account-provisioning step and cryptographic means to bind an
> > intent to authorize a given name by a given account to the actual
> > challenge and challenge-validation steps are important parts of
> > achieving the properties that ACME provides.
> >
> > >
> > >
> > > [1]
> > > https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-20#section-8.8
> > >
> > > Cc: [email-masked] <mailto:[email-masked]>
> > > <[email-masked] <mailto:[email-masked]> >; [email-masked]
> > > <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]> >;
> > > [email-masked]
> > > <mailto:[email-masked]> >;
> > > <[email-masked] <mailto:[email-masked]> >
> > > I think you are correct that PKI structure and how to validate IPN
> > > and DTN URI in regards to the certificats are seperate document.
> > >
> > > So don't we have two different aspects here for TCPCLv4. One when it
> > > is used as CL to reach a next hop in the routing infrastructure,
> > > where the sending agent only need to know that it connected to the
> > > intended next hop. The other case is when the agent uses the CL to
> > > directly reach the peer agent with the intended BP layer destination
> > > Node ID. Maybe I have focused to much on the later and it is only
> > > the former that actually are needed here. Still BP routers do have
> > > their own Node ID and thus, I guess the identification dilema for
> > > Node IDs do remain.
> >
> > originally proposed for IESG Evaluation.  It's not a problem that's
> > fully solvable, though, so we'll need to clearly document what we
> > do/don't do and move on, as was noted later in the thread.)
> >
> 
> 
> 
> --
> Cheers
> 
> Magnus Westerlund
> 
> 
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn