Re: [dtn] Martin Duke's Discuss on draft-ietf-dtn-tcpclv4-22: (with DISCUSS and COMMENT)

[Martin Duke <[e-mail]>]

Hi Brian,

I believe you may be right about TLS certificate validation. In any case,
Ben Kaduk appears to be raking through the cert validation text quite
carefully, and is far more qualified in this area than me. I'm happy to
withdraw that particular comment.

Martin

On Mon, Nov 9, 2020 at 9:19 PM Brian Sipos <[e-mail]> wrote:

> Martin,
> This appears to be getting close. The one remaining comment is related to
> TLS handshake and failures.
>
> One reason for some of this trouble, I think, is the lack of obvious
> pre-existing concrete requirements for the *use of* TLS [1] by
> application protocols. I'm looking through references to TLS [2] for both
> "proposed standard" status and "normatively references" type, and see many *extensions
> to* TLS and many references to *data used by *TLS but for the *use of*
> TLS I see only NTP [3] and its requirements are quite loose and certainly
> don't include a protocol state machine definition of how TLS fits in.
>
> There seems to be a kind of assumption in protocol specifications that
> using TLS just lets the implementation of TLS "do its thing" even though
> TLS itself *explicitly *excludes doing things like certificate validation
> in Section 4.4.2.4:
>
> In general, detailed certificate validation procedures are out of scope
> for TLS (see [RFC5280]).
>
>
> The use of TLS for TCPCL has its own specific issues related to some of
> the certificate validation (DNS name) happening within the TLS
> implementation during handshake and some (Node ID) happening after the
> handshake has completed, when many TLS APIs don't allow injecting arbitrary
> Alerts into the TLS message stream. Sending a post-TLS-handshake SESS_TERM
> seems to be allowed by TLS itself and a reasonable way to avoid
> intermingling of CL-level messaging with TLS-level messaging.
>
> Considering all that, is there a good RFC to point to as an example of a
> well-specified example of using TLS 1.3 (or even an earlier version) in a
> way which is actually compatible with TLS implementations?
>
> Thanks again for your feedback,
> Brian S.
>
> [1] https://tools.ietf.org/html/rfc8446
> [2] https://datatracker.ietf.org/doc/rfc8446/referencedby/
> [3] https://tools.ietf.org/html/rfc8915
> [4] https://tools.ietf.org/html/rfc5280
>
>
> ------------------------------
> *From:* Martin Duke <[e-mail]>
> *Sent:* Monday, November 9, 2020 17:30
> *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: Martin Duke's Discuss on draft-ietf-dtn-tcpclv4-22: (with
> DISCUSS and COMMENT)
>
> Hi Brian,
>
> On Sun, Nov 8, 2020 at 5:49 PM Brian Sipos <[e-mail]> wrote:
>
> Martin,
> My responses are in-line below with prefix "BS1".
>
> >
> > First of all, "failure of the transfer" is ambiguous because there
> > may be two
> > transfers going on, one in each direction.
> >
> BS1: This phrasing is a bit unclear because the statement applies to
> the transfer itself. Instead of "a transmitting node" it should be "a
> node transmitting a transfer" so the subject of the statement becomes
> the outgoing transfer.
>
>
> Yes, that would help.
>
>
>
> > Second, I would like further clarity on what it means that nodes
> > "SHALL"
> > consider it "a failure of the transfer". What is actionable if it's a
> > failure?
> > If nothing is actionable, it shouldn't be a SHALL. Does this mean
> > that in
> > subsequent sessions I must resend the whole bundle?
> >
> BS1: There are requirements about how a CLA interacts with its
> overlaying BPA, and this requirement applies to what will be indicated
> to the BPA about the formerly-in-progress transfer. Section 3.1
> explains that CLA--BPA interface.
>
>
> This reply makes sense. Perhaps a reference to Sec 3.1 would help?
>
>
>
> > Can you list some reasons why an endpoint would choose to close
> > uncleanly? Some
> > motivation might provide helpful context.
> >
> BS1: The motivation here is that there are some reasons why the CLA
> will know that it's about to lose connectivity and send a positive
> indication of "I'm about to go away and cannot finish a transfer (in
> either direction)" instead of waiting (potentially a long time) for a
> CLA timeout or a TCP timeout. For example, a low battery starting into
> a power saving mode and stopping a data link. This is as opposed to a
> clean termination, which is not time-critical and more of a "I don't
> want to start any more transfers, so don't attempt any new ones."
>
>
> Thanks. Maybe add a sentence about this? "For instance, an endpoint may
> know it's about to lose connectivity and request abrupt termination rather
> than forcing a timeout."
>
>
>
> > Moreover the "sending or receiving" bit is confusing.
> > - So one option is that I'm a session that has decided to do an
> > unclean
> > termination rather than a clean one. So I send SESS_TERM and then
> > close (FIN?
> > RST?) the TCP connection. So if it's a FIN, I might very well get the
> > last
> > XFER_ACK.  If I RST or don't get that ACK, then I do think it's clear
> > that the
> > transfer is a failure, whatever that means.
> >
> BS1: I can add a top-level requirement that closing a TCP connection
> always means using a FIN.
>
>
> Thanks.
>
>
>
> > - But as a receiver, how do I know that the termination is unclean?
> > Have I made
> > an independent decision to close uncleanly? Am I to take the receipt
> > of a
> > SESS_TERM without my having sent XFER_ACK as an unclean close? If I
> > sent
> > XFER_ACK, how do I know that the sender sent it? And what does it
> > mean, as a
> > receiver, that the transfer "failed" if I have all the data?
> >
> BS1: Some of these requirements may be trying to overspecify behavior
> and just get confusing. There is always the potential for the TCP
> connection to close for some other reason outside the CLA's control.
> Maybe a better set of requirements is to mention that a peer MAY close
> the connection before a transfer is finished, and that a closed
> connection before receiving the final XFER_ACK SHALL be treated as a
> failed transfer (even outside of an unclean termination, because at
> that point there is no possibility of ever receving that final ACK).
>
>
> I think that would be an improvement
>
> Some clearer description of when an endpoint TCPCL should send close to
> its TCP, given receipt of a SESS_TERM and FIN, would be helpful. For most
> SESS_TERMs, I don't want to send FIN until I have both completed any
> in-progress transmission, and have XFER_ACKed all incoming segments. In the
> unclean case I probably want to send a FIN more or less immediately to
> avoid a timeout, I think (?), and some guidance on how to distinguish these
> cases would make this clearer.
>
>
> >
> > ---------------------------------------------------------------------
> > -
> > COMMENT:
> > ---------------------------------------------------------------------
> > -
> >
> > Thanks for this document. I have numerous minor concerns:
> >
> > Sec 4.3. "the TCP connection SHALL be closed." Can you clarify if
> > this is a
> > clean close (FIN) or abort (RST)? In fact, if you always mean FIN, it
> > might be
> > good to clarify that in the terminology section to indicate that
> > there are no
> > RSTs anywhere.
> >
> BS1: as mentioned above, I will add a requirement that FIN is the
> correct method.
>
>
> Thanks
>
>
>
> > Sec 4.3. VERSION_MISMATCH would benefit from being split into
> > VERSION_TOO_HIGH
> > and VERSION_TOO_LOW. For example, if the passive is at v4 only and
> > the active
> > supports v1, v2, and v3, it will take three tries to figure out that
> > there is
> > no way for these nodes to communicate. Even better would be a QUIC-
> > style
> > Version Negotiation message that would communicate the options in 1
> > RTT.
> >
> BS1: This had been discussed in the WG somewhat and this is a carry-
> over from the behavior of the TCPCLv3.
> The current requirements on the actie entity are to start at the
> highest supported version and on the passive entity are to begin
> TLS/session negotiation on *any* acceptable TCPCL version, which
> assumes that a later version will be more acceptable to an arbitrary
> passive entity.
> Adding a "supported versions set" to the Contact Header is possible,
> but there needs to be WG discussion on whether this is a worthwile late
> addition.
>
>
> If it's routine for a node that supports v4 to also support earlier
> versions, than I agree there is no serious problem here.
>
>
>
> > There are few items that seem to be artifacts of TLS happening after
> > session
> > negotiation in v3:
> >
> > Sec 4.4.3. "If certificate validation
> >    fails or if security policy disallows a certificate for any
> > reason,
> >    the entity SHALL terminate the session"
> >
> > I don't understand this; certificate validation generally occurs
> > during the TLS
> > handshake, where there is no session?
> >
> BS1: There is a bit of gray area when the TLS handshake is involved,
> because it can either succeed or fail but after the handshake it is
> possible to send TCPCL messages regardless of handshake success. I
> suppose that if the TLS stack fails within the TLS handshake that there
> will be a TLS-level message indicating this fact and the TCPCL-level
> message is redundant. Using the SESS_TERM regardless of whether the TLS
> stack rejected the handshake or the CLA rejected the peer certificate
> guarantees that there is some over-the-wire indication of what went
> wrong (as opposed to the connection just being closed after a seemingly
> valid TLS handshake).
>
>
> I am uneasy about this response. The TLS alert mechanism can already
> signal the peer when there is a problem with the handshake. However, many
> TLS stacks deliberately obscure the precise reason for handshake failure to
> avoid attacker analysis. This text treats cert validation as something
> outside the handshake, which I don't believe is correct.
>
>
>
> > Sec 4.4.3
> > "the active
> >    entity SHALL authenticate the DNS name (of the passive entity)
> > used
> >    to initiate the TCP connection"
> > s/TCP Connection/TLS session. TCP connections don't consider DNS at
> > all.
> >
> BS1: This may be a phrasing issue, maybe instead:
>    Either during or immediately after the TLS handshake if the active
>    entity resolved a DNS name (of the passive entity) in order to
>    initiate the TCP connection, the active
>    entity SHALL authenticate that DNS name using any DNS-ID of the peer
>    certificate.
>
>
> LGTM.
>
>
>
> > Sec 4.5.
> > "After the initial exchange of a Contact Header, all messages
> >    transmitted over the session are identified by a one-octet header
> >    with the following structure:"
> >
> > Obviously, TLS handshake messages are after the Contact Header and
> > are not
> > prepended by these headers. Perhaps this is an artifact from v3?
> >
> BS1: This is an artifact, it should be clarified as:
>     After the initial exchange of a Contact Header and any TLS
>     handshake exchanges, ...
>
>
> LGTM
>
>
>
> > Sec 4.7
> > "Once this process of parameter negotiation is completed (which
> >    includes a possible completed TLS handshake of the connection to
> > use
> >    TLS),"
> >
> > The TLS handshake occurs before parameter negotiation.
> >
> BS1: This is a vestigal behavior and needs to be rephrased to remove
> that parenthetical.
>
>
> Yep
>
>
>
> > Sec 5.2.4 I find it odd that each CL would have its own set of reason
> > codes
> > that it will simply pass to the bundle layer. Far better for it to be
> > a common
> > set of CL-agnostic errors that the bundle layer implements, as they
> > literally
> > do not matter to the CL at all.
> >
> BS1: There had been earlier WG discussion about a standardized CLA--BPA
> interface and nomenclature, but the CLA capabilities are incredibly
> link-layer dependent and not at all consistent, especially ways in
> which a transfer can fail (some link layers are even unidirectional and
> don't provide any feedback at all to the CLA).
> This could be discussed in the WG to see if the consensus has evolved
> in any way in the meanwhile.
>
>
> OK, I don't think it's necessary to revisit consensus on this.
>