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

[Magnus Westerlund <[e-mail]>]

Hi Brian, 

 

I think we are getting very close to what the text here needs to say. What I
think is missing is being explicit that the peer acting as TLS client if it
includes the SNI, it needs to include the hostname related to the Node ID.
Being clear that it will be up to the deployments and their addressing and
naming schemes to make this relation explicit if it exist. 

 

The TLS authentication part already have the same implication when it comes
to hostnames and Node IDs so I don't see that you get rid of any potential
pitfalls here regarding the hostname and Node ID relationship, that is
anyway present. 

 

Maybe the way of resolving this is simple to add a paragraph earlier in the
draft to discuss the hostname to Node ID relationship that likely exists in
a deployment utilizing this CL. 

 

Cheers

 

Magnus Westerlund

 

 

 

From: Brian Sipos <[e-mail]> 
Sent: den 1 oktober 2019 15:53
To: Magnus Westerlund <[e-mail]>; [e-mail];
magnus.westerlund=[e-mail];
[e-mail]
Subject: Re: [dtn] AD review of draft-ietf-dtn-tcpclv4-12

 

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] <mailto:[e-mail]> ;
magnus.westerlund=[e-mail]
<mailto:magnus.westerlund=[e-mail]> ;
[e-mail] <mailto:[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]
<mailto:[e-mail]> 
----------------------------------------------------------------------