Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

From: Brian Sipos <[email-masked]>
Date: Fri, 27 Sep 2019 18:23:49 +0000

Magnus,
>From your earlier message regarding BCP 195, that is excellent news that no change is needed.

Regarding SNI, your expectation is correct and the current phrasing is not explicit enough. Where it says:

The SNI SHALL contain the same host name used to
establish the TCP connection.

it should more accurately say:

The SNI SHALL contain the host name of the passive node
which was used to establish the TCP connection.

There may be a yet nicer way to phrase this; any suggestions are welcome.

________________________________
From: Magnus Westerlund
Sent: Friday, September 27, 2019 04:30
To: [email-masked]; magnus.westerlund=[email-masked]; [email-masked]
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

Hi,

So looking at -14 I think the remaining issue is only the question if the SNI
field is the right one. I think you may have to educate me here that this is the
right way. However, please my comment below.

On Tue, 2019-09-17 at 19:47 +0000, Magnus Westerlund wrote:
>
> > Figure 8 and 10: Uses [SESSTERM] is this the same as using the
> > SESS_TERM message, or some other procedure. Please clarify.
>
> Okay looking at this again it is clear that [SESSTERM] is used for any
> type of session termination. However, as SESSTERM appears to only be
> used in the figures in that meaning, and being defined in Figure 13,
> despite existing in 8, 9 and 10 also. Also considering that Figure 13
> and 14 are signalled termination and the other are failure cases I
> think a sentence or two should be spent to explain its meaning prior to
> its usage.
>

The changes do make the process around SESS_TERM message clearer. I think this
is now resolved.

>
> >
> > Section 4.4: So what about entity authentication? Will the TCPCL
> > entity have a name / identity that can be authenticated so that one
> > know that one are talking to the right entity. And is the solution
> > for this a classical PKI, or something else? Also does the passive
> > entity expect the active (TLS client) to authenticate itself also?
>
> Mostly good new text on the authentication. Here I am going beyond my
> expertise, but based on that RFC 5280 has been updated several times, I
> think you need to figure out if any of these updates should be
> indicated as necssary for TCPCLv4. The relevant updates are RFC 6818
> which makes clarifications on RFC 5280 and then the intenationalization
> in RFCs 8398, 8399.

This part is resolved.

>
> The other concern I have is the SNI sentence: "The TLS handshake SHOULD
> include a Server Name Indication from the active peer." First of all
> you need a reference for server name indication. It is an TLS extension
> and not included in the main TLS specification. For TLS 1.2 it is
> section 3 of RFC 6066. The second part is that I don't think it is
> clearly specified what should be in the SNI field in TLS. Looking at
> the DTN URI scheme definition I would guess that only the node-name
> part of the URI should be included, or?

The new text is very clear on how the SNI field is to be used. However, now it
is Client Hostname Indication rather than the Server Name Indication field.
Without understanding the name and addressing schemes of DTN I have a hard time
to judge if this makes sense or not. I find it a bit backwards to say the least.
If a BP Agent (Charlie) has bundle that is to be delivered to dtn://foo/bar and
does a name resolution of "foo" to learn that foo supports TCPCLv4 and has a
host name of node4.foo.com which maps to an ip 100.10.10.50:5432. The fact that
when Charlie is establishing the TCP/TLS connection it will do a TCP connect to
100.10.10.50:5432 and then the TLS SNI Field says "Charlie". How will the server
entitiy at 100.10.10.50:5432 location know that Charlie is suppored to talk to
node4.foo.com rather than node9.delta.com if they actually are co-located? I
would have expected that SNI would indicate the host, in this case node4.foo.com
rather than Charlie.

>
> This also relates to the section 4.4.2 TLS host name validation part.
> It says that certificates subjectAltName should be the Node ID. That
> raises question marks as no part the DTN URI format defines something
> as Node ID. The second is what happens if someone uses another URI
> scheme with BP? Or maybe this is simple to resolve if the whole URI
> should be used, but that looks less than obvious at least in the case
> of DTN. And I haven't looked at the IPN scheme.

To me this part now looks clear.

Cheers

Cheers

Magnus Westerlund

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 30 Sep 2019 09:23:25 +0000

Hi Brian,

> > which was used to establish the TCP connection.

I think this formulation is a bit strange. The host name may first of all never
have been used to establish the TCP connection, that assumes a DNS or similar
name lookup schemem to find the peer. Secondly, I think it needs to more direct
say that you include the host name that are associated with the intended peer's
identity. This both for TLS server certificate selection, but also traffic
routing to the correct bundle protocol level entity. 

There exists to me a chain here that looks like this:

host name -> TLS Server Identity -> a set of Node IDs

Cheers

Magnus Westerlund