Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-09.txt

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Brian,

On Sun, Oct 28, 2018 at 2:41 PM Brian Sipos <[e-mail]> wrote:

> Joerg,
> I'm making edits based on your comments below, and have included
> replies inline below also.
>
> On Mon, 2018-08-13 at 22:36 +0200, Joerg Ott wrote:
> > [Now including the DTN WG list]
> >
> > Hi everybody,
> >
> > I am guilty of having had less than adequate time lately to look at
> > the
> > detailed evolution of this draft.  I did a detailed review that
> > yielded
> > a number of comments.
> >
> > As a meta note up front: I am not super-happy that the document more
> > than doubled in size, while the functionality did not grow that much
> > (luckily).  There seem to be lots of precautions taken for future-
> > proofing, while some of those could be addressed by another rev.
> > I specifically also went back to v3 to compare the changes.
> >
> > I am also puzzled about the generous choice of field sizes given that
> > the bundle protocol itself uses encodings that aim at wire
> > efficiency.
> >
> > I don't wanna bring up everything at once but here are a few bits
> > that
> > I really think need to be fixed.  So let me keep the discussion
> > focused
> > for now (we can look at nits later on):
> >
> > 1. Section 4.3 seems to suggest on p21 (a node may adapt its
> > operation
> >     to an older version of the protocol) the two endpoints might
> > choose
> >     using different protocols versions, which is surely problematic.
> >     The outcome of this negotiation must be unambiguous.
> >
> I've added specific logic based on the two roles (active vs. passive)
> to disambiguate the behavior and make understanding when the session
> transitions state to parameter negotiation.
>
> > 2. Section 4.4 discusses TLS but this isn't enough.  TLS has lots of
> >     parameters, TLS clients may and servers must have certificates.
> >     All this interaction needs to be spelled out.  What about the APN
> >     to be used for TLS connection setup.  And, of course, we should
> > use
> >     TLS 1.3.
> >
> As was mentioned by others in earlier replies, this spec relies on
> RFC7525 for TLS best practices, version support, and default
> ciphersuite support and use.
>

I woke up reading this, and went to check your draft, which has

    The use of TLS is negotated using the Contact Header as described in
   Section 4.3.  After negotiating an Enable TLS parameter of true, and
   before any other TCPCL messages are sent within the session, the
   session entities SHALL begin a TLS handshake in accordance with
   [RFC5246].  The parameters within each TLS negotiation are
   implementation dependent but any TCPCL node SHOULD follow all
   recommended best practices of [RFC7525].  By convention, this
   protocol uses the node which initiated the underlying TCP connection
   as the "client" role of the TLS handshake request.

That's an excellent start. I have two comments (do the right thing).

   - The larger point - pointing to RFC 7525 is a reasonable starting
   place, but RFC 7525 is a BCP (specifically, BCP 195), which can be updated
   or (especially) obsoleted. If you said "all recommended practices of
   [BCP195], or any updates or successors that become part of [BCP195]", that
   would be a lot more future-proof.
   - I understand that this is a SHOULD for a reason, but if you can give
   examples of reasons why an implementation that doesn't do this would still
   be doing the right thing, that would likely make your IETF Last Call
   comment discussions, including interactions with SECDIR reviewers, and with
   ADs during IESG Evaluation, terminate more quickly and more pleasantly.

Thanks,

Spencer