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

[Brian Sipos <[e-mail]>]

Magnus,
You are correct that the SNI is only meaningful when an actual host name (likely resolved via DNS) is used to establish the TCP connection. For stand alone one-BP-agent--one-TCPCL-entity--one-host-name uses, the SNI will serve no purpose. I expect that the more typical case is where each TCPCL entity has only one X.509 certificate which authenticates a single Node ID (and possibly, but not necessarily, a stable host name or IP address).

The SNI use is to handle what I would consider to be more rare circumstances where one TCPCL entity is used with multiple DNS names in a "virtual host" kind of situation. Or where PKI policy disallows multi-name or wildcard certificates but the TCPCL entity might be accessed via multiple address or multiple host names, and so has to present a different certificate depending on how it was addressed by the TLS client.

The reason why I included it in the spec is that many TLS-using libraries (including the two I used for my own implementation) send an SNI anyway and there is no harm in providing an SNI that the passive peer (server) ignores. If this all seems like too much of a specialized use case then I'd rather remove then SNI language and leave it up to the network administrators to work out situations like this. I'm sure that there are many more odd situations caused by PKI or network policy decisions.

________________________________
From: Magnus Westerlund
Sent: Monday, September 30, 2019 05:23
To: [e-mail]; magnus.westerlund=[e-mail]; [e-mail]; Brian Sipos
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

Hi Brian,

On Fri, 2019-09-27 at 18:23 +0000, Brian Sipos wrote:
> 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.
>

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


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------