Subject: [Netconf] review of draft-ietf-netconf-ssh-client-server-03 and draft-ietf-netconf-tls-client-server-03

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Aug 2017 13:26:19 +0200

Hi,

I took a look at both documents today and I am attaching my two
reviews.  Since the structure of the documents is quite similar, the
review comments are also quite similar.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Aug 2017 15:54:14 +0200

> review comments are also quite similar.

One more thing:

Since ietf-ssh-client, ietf-ssh-server, ietf-ssh-common essentially
define only groupings (one grouping per module) and identities, I
suggest to merge these definitions into a single module, say
ietf-ssh-common. This way, the module name ietf-ssh-server can be used
(later) to define an instantiation of the groupings for a standalone
SSH server.

I would suggest the same for the ietf-tls-* modules (even though there
is not a common standalone TLS server).

Since these modules will have conformance-type 'import' in YANG
library, I do not really see what the benfit of splitting things
into multiple modules. What you implement is defined by the modules
using the groupings.

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 10 Aug 2017 20:11:11 +0000

Hi Juergen,

> review comments are also quite similar.

Thanks!  And, to make responding easier, I've copied/pasted both
sets of comments in below.

Kent

For the ssh-client-server draft 
===============================

> - The overall setup is somewhat complicated but I do understand why.
>  Obviously, the attempts to make things generic come with a price
>  since many YANG definitions interact with other definitions that
>  need to be understood. And while the end result is that we can
>  configure SSH clients and servers for NETCONF, we only have a
>  collection of groupings to configure a regular SSH client or
>  server. Should we have an instantiation of these groupings for
>  regular SSH clients and servers as well?

I'm hoping to not have to do this, but can see that there might be
value in doing so in order to further proof-out the model.  To do
this right would entail something like what Clyde did for the syslog
model in evaluating many vendor's implementations to find a common
denominator.  I can imagine the WG undertaking such an analysis for
an SSH-server container, but I fail to see how it could be done for
an SSH-client container.  Also, when thinking about symmetry to the
tls-client-server draft, note that the idea of creating a container
for a TLS-server doesn't make sense (which one, right?)

>  To create a YANG model for a regular SSH server (for system level or
>  CLI access), one would have to implement the ietf-keystore model,
>  write a YANG module to suitably instantiate the
>  ietf-ssh-server:ssh-server-grouping and likely use some
>  endpoints-container grouping (well this has not been factored out
>  yet but I get to this in a different review).

Yes, it would be an exercise like this.

>  Obviously, reusability comes with a certain price in complexity and
>  I guess this is why we often had WG meetings where Kent asked
>  questions but nobody felt to respond. Anyway, if we create these
>  reusable components, we need to find a name for them.  Saying these
>  are SSH client and server models (as the title does) is likely
>  confusing people since the definitions are really only meaningful if
>  instantiated in other contexts. The simplest change might be to
>  change the title to "YANG Groupings for SSH Clients and SSH
>  Servers".

Yes, awkward silence, and now here we are.  For now, I've change 
the title as suggested.  I also made the similar change for the 
tls-client-server draft.

>- The text in section 2 points out as an example X.509v3 certificate
>  based host keys. I think these are far less common than regular SSH
>  host keys. If so, perhaps we should use a different example?  It
>  might be useful to explain that X.509v3 certificate host keys are
>  actually a YANG feature, i.e., not expected to be implemented
>  everywhere. The example requires to understand the keystore model.
>  Can a more complete example be provided that incorporates part of
>  the keystore?

Looking that the example, the intent is that the ssh-client is
authenticating the server using 'explicitly-trusted-ssh-host-keys',
and is authenticating itself to the server using 'ex-rsa-key'.
Neither of these are X.509 keys, but I see just below, in the
<transport-params> section, the client passing host-key-algs that
include an X.509 alg.  I just removed that host-key-alg from the
listing (and made a similar change to the ietf-ssh-server model).

We could copy/paste the keystore example, but isn't the following
note just above the example good enough?
 
   This example is consistent with the
   examples presented in Section 2.2 of [I-D.ietf-netconf-keystore].

> - Copyright year should be 2017 not 2014 (update required in multiple
>  places).

This was fixed previously.

> - Document authors and YANG module authors do not line up.

Fixed (in the tls-client-server draft too)

> - 'for just the SSH configuration omitting' - should there be a comma
>    before omitting to get the structure of the sentence straight? Or
>    break into two sentences?

Added a comma (in tls-client-server too)

> - s/is authenticate/is authenticated/

Fixed.

> - The example in 3.2 is again X.509 centric. Would be nice to see the
>   more common case as well. It is also difficult to understand the
>   example without seeing the corresponding part of the keystore model.

Same fix and comment as above.

> - The identities in ietf-ssh-common probably need to be moved to IANA
>   and there likely need to be proper procedures for managing the
>   identities.  Are the identities clearly SSH specific? If not, the
>   management will likely be more complex.

Right, and this is related to the keystore identity issue as well.
https://github.com/netconf-wg/keystore/issues/8.

> - I think it is a good practice to introduce for every base identity a
>  corresponding specific identityref type so that tree diagrams etc
>  have a more readable type. The pattern is:
>
>  identity foo {
>    description
>     "Abstract base identity for foos.";
>  }
>
>  typedef foo-ref {
>    type identifyref { base foo; }
>    description
>      "A foo identity reference.";
>  }
>
>  And then you use foo-ref as the type in the data models that refer to
>  foo identities.

All of the identities are in the "ietf-*-common" modules (Gary, can you
please take care of this one?).  That said, there's still the larger 
issue of us moving all the identities into some other module.

> - Security considerations: This may need some rewriting since there is
>  really no data tree. The general template does not really work well
>  for modules only defining reusable groupings. I think what is really
>  needed here are guidelines for authors of documents using the
>  groupings. Also remove text that clearly is irrelevant (there are no
>  RPC so why spent a paragraph on them).

I added this sentence (to both drafts):

  Since the modules defined in this document define only groupings, 
  these considerations are primarily for the designers of other
  modules that use these groupings.

I also change "module" to "modules", since the draft defines more
than one.

I left the "RPC" paragraph (and both the RPC and "readable nodes"
paragraphs in the tls-client-server draft).  These paragraphs have
a place where a list of nodes are to be supplied.  In this case,
my putting "NONE" seems to 1) preserve the template and 2) indicate
that the consideration was analyzed.  This is unchartered waters
but, it seems that we'd want the considerations to be explicit in
what all it considered.

For the tls-client-server draft
===============================

> - As noted in my review of the SSH equivalent, I suggest to change the
>  title to something like "YANG Groupings for TLS Clients and TLS
>  Servers".

Fixed (per above comment)

> - Copyright year should be 2017 not 2014 (update required in multiple
>  places).

Fixed (per above comment)

> - Document authors and YANG module authors do not line up.

Fixed (per above comment)

> - In section 2, should there be text that says what happens if there
>   is not client authentication configured or how to extend this for
>   authentication types commonly found on the web for instance?

Why should there be, isn't that a protocol-specific issue?  For instance,
per comments from before, the ietf-netconf-client and ietf-restconf-client
models add 'must' statements asserting client-authentication is configured.
Is this something that should be mentioned in Security Considerations?

>- 'for just the TLS configuration omitting' - should there be a comma
>   before omitting to get the structure of the sentence straight? Or
>   break into two sentences?

Fixed (per above comment)

> - Does the TLS server not need to know which key to use? I only see
    a reference to a certificate to use.

I don't know which node you're looking at, but there is one reference
to a certificate that is under a specific key, and there is another
reference to a set of certificates that is not associated with any key.

> - With web servers, things are often more complicated since you only
>   know which key/certificate to use once you know which site is being
>   accessed. The Server Name Indication (SNI) TLS extension [RFC 6066]
>   deals with this. How could this be factored into the YANG server
>   grouping?

I'm unsure what you're saying.  A client is configured to connect to a
specific site, but it doesn't know what site it will actually connect
to, and hence can't be configured to know which certificate to use?

This sounds a lot like what was discussed before about configuring
NC/RC clients to authentication to call-home connections.  We decided
to just support a single set of auth params that would be used for all
servers (and not define a server-id to client-auth mapping).  So, this
grouping may not work well in some examples.  Is it okay?

> - The description of the list certificate says "unordered list of
>   certificates the TLS server can pick from when sending its Server
>   Certificate message.". So how does the server pick the certificate?
>   Is the idea that the somewhat vague text takes care of SNI? What if
>   SNI is not used, which certificate is picked? How does the server
>   pick the corresponding key? (Or are these certificates assumed to
>   all be associated with the same key?)

I'm looking at https://tools.ietf.org/html/rfc5246#section-7.4.2:

   If the server has multiple certificates, it chooses one of them based
   on the above-mentioned criteria (in addition to other criteria, such
   as transport layer endpoint, local configuration and preferences,
   etc.).

> - The identities in ietf-tls-common probably need to be moved to IANA
>   and there likely need to be proper procedures for managing the
>   identities.  Are the identities clearly TLS specific? If not, the
>   management will likely be more complex.

I don't know if these identities are TLS-specific or not.  Gary?

> - I think it is a good practice to introduce for every base identity a
>   corresponding specific identityref type so that tree diagrams etc
>   have a more readable type. The pattern is:
> 
>   identity foo {
>     description
>      "Abstract base identity for foos.";
>   }
>
>   typedef foo-ref {
>     type identifyref { base foo; }
>     description
>       "A foo identity reference.";
>   }
>
>  And then you use foo-ref as the type in the data models that refer to
>  foo identities.

Being discussed in above comment.

> - Security considerations: This may need some rewriting since there is
>   really no data tree. The general template does not really work well
>   for modules only defining reusable groupings. I think what is really
>   needed here are guidelines for authors of documents using the
>   groupings. Also remove text that clearly is irrelevant (there are no
>   RPC so why spent a paragraph on them).

Fixed (per above comment)

Thanks again,
Kent

---

From: "Gary Wu (garywu)" <[email-masked]>
Date: Thu, 10 Aug 2017 23:10:22 +0000

Hi Kent/Juergen,

My responses in-line.

BTW, I've updated the github addressing some of the previous comments,
you might want to merge your local copies.

Thanks,
Gary

On 8/10/17, 1:11 PM, "Netconf on behalf of Kent Watsen" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Juergen,

    
    Kent

    

    

    

     

    

    
    Fixed.

    
    
<GARY>
They are SSH-specific in that they come from the IANA registry for the SSH
protocol.  It would be difficult to come up with protocol-independent identities
as different protocols have different ideas as to an algorithm 'unit' is.  For
example, in SSH you specify KEX algorithms separate from MAC algorithms, but in
TLS the combination of those plus other algorithm types constitute a cipher
suite.

If we move the identities to an iana-* module, I suppose the expectation is that
every IANA number has an associated YANG identity.  In that case, do we want to
have an if-feature for every identity (there are hundreds and they are almost
all optional-to-implement)?  Or do we want to get rid of if-features altogether
and let the management agent return an error when it can't support the requested
configuration?
</GARY>

    
<GARY>
I had suggested defining types for the leafrefs to (trusted-){keys, certs} in
the keystore module, so that modules using keystore won't need to refer to
paths in keystore and removes their coupling to the structure of keystore.
There isn't as big a benefit to encapsulating identityrefs.  The node
identifiers are descriptive of their type and I kind of like knowing that a type
is an identityref without referring to the typedef, but I think a case can be
made for consistency.
</GARY>

    

    

    

    

    

    
    
<GARY>
We haven't explored virtual hosting.  I think the server grouping could be used
as it currently is, because each virtual host could have a separate TLS
configuration, although I don't know if any real-world implementations support
the full set of TLS configurations for each virtual host.

Here's a hypothetical web server config, the SNI would be inferred from
'server-name', which is an application-level config.

e.g.:
  <web-server>
    <use-tls>true</use-tls>
    <ip-address>0.0.0.0</ip-address>
    <port>443</port>
    <virtual-host>
      <server-name>foo.com</server-name>
      <tls-server-cfg>
        <certificate>foo_cert_1</certificate>
        <certificate>foo_cert_2</certificate>
      </tls-server-cfg>
    </virtual-host>
    <virtual-host>
      <server-name>bar.org</server-name>
      <tls-server-cfg>
        <certificate>bar_cert_1</certificate>
        <certificate>bar_cert_2</certificate>
      </tls-server-cfg>
    </virtual-host>
  </web-server>

</GARY>

    

    
<GARY>
Same comment as above for SSH.
</GARY>

    

    Thanks again,
    Kent

    _______________________________________________
    Netconf mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Aug 2017 16:24:28 +0200

> For the ssh-client-server draft 

Yes, for TLS there is no a common standalone TLS service. For SSH,
there is however since SSH was created for a specific service (while
TLS was created as a plugin to secure another existing service).

The client question we discussed before and I tend to agree that
usually a client you configure is embedded into some other
functionality that likely has its own configuration, so having a
grouping is OK.

But since there are SSH servers out there, do we expect this ID to
just provide groupings and we hope that some other module later comes
along and picks up the groupings and turns them into a more general
SSH server configuration model?

My understanding is that NC implementations actually come in different
forms, some simply running behind a regular SSH server while others
come with their own integrated SSH server. Does this affect the data
model?
 
> Yes, it would be an exercise like this.

So you are saying I guess this is the direction you see this to evolve.
 
> the title as suggested.  I also made the similar change for the 

OK

>    examples presented in Section 2.2 of [I-D.ietf-netconf-keystore].

As a reader, having to look at multiple RFCs is a bit harder. During
production of the RFCs, how do we make sure things stay aligned? Well,
this problem exists in any case.
 
> https://github.com/netconf-wg/keystore/issues/8.

Yes.
 
> issue of us moving all the identities into some other module.

It is not clear whether one module is the answer, i.e., whether the
identities are identical between security protocols or whether they
traditionally all do their own little soup. If the later, then this is
likely how it works in practice. So the security WGs actually
coordinate when they need a new name / label for a security mechanism?
If not, creating a central module is going to lead to headaches for
those in charge to maintain it.

>   modules that use these groupings.

OK

> but, it seems that we'd want the considerations to be explicit in

Personally, I prefer to not see text that does not apply in the final
document. Perhaps decorate this with an RFC editor instruction to
remove the text during the final stages of the process.
 
> Is this something that should be mentioned in Security Considerations?

I think it would help to spell out 'if no client auth configured,
there is no client auth; if you want to always have client auth, a
must statement can be used'.
 
> reference to a set of certificates that is not associated with any key.

Ah, it is a leafref to .../key/certificates/certificate - I did not
catch that.
 
> to, and hence can't be configured to know which certificate to use?

No, the server starts a TLS handshake but it does not yet know which
site hosted on the server the client goes to and hence the server does
not know which certificate to use. In HTTP, it is the Host: header
that tells the server which virtual host you talk to. TLS happens
before that and hence the TLS server either has to guess the right
certificate (bad) or the TLS client uses SNI to let the server know
during the TLS exchange which Host: he wants to talk to. The point
here is that the assumption that a listing transport endpoint maps to
a specific certificate in general is not true.

> grouping may not work well in some examples.  Is it okay?

Perhaps not supporting SNI is sufficient for network management
purposes but then also pretty clearly the TLS groupings are not
generally usable.

>    as transport layer endpoint, local configuration and preferences,

So the server magically picks one. This may be OK for the TLS spec to say,
not sure this is sufficient for a configuration spec.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Aug 2017 16:31:30 +0200

On Thu, Aug 10, 2017 at 11:10:22PM +0000, Gary Wu (garywu) wrote:

> <GARY>
> They are SSH-specific in that they come from the IANA registry for
> the SSH protocol.  It would be difficult to come up with
> protocol-independent identities as different protocols have
> different ideas as to an algorithm 'unit' is.  For example, in SSH
> you specify KEX algorithms separate from MAC algorithms, but in TLS
> the combination of those plus other algorithm types constitute a
> cipher suite.  If we move the identities to an iana-* module, I
> suppose the expectation is that every IANA number has an associated
> YANG identity.  In that case, do we want to have an if-feature for
> every identity (there are hundreds and they are almost all
> optional-to-implement)?  Or do we want to get rid of if-features
> altogether and let the management agent return an error when it
> can't support the requested configuration?
> </GARY>

This is what I expected (that the identities are protocol specific).
Personally, I do not think it is useful to define large numbers of
features and servers should reject identities not supported. The
question is whether there should be config false list of identities
supported so that a client does not have to do trial and error.

> is an identityref without referring to the typedef, but I think a case can be

I agree that identities for the references into the keystore lists are
even more useful.

>         <certificate>bar_cert_2</certificate>

This might work.

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 17 Aug 2017 20:42:11 +0000

Hi Juergen,

I've trimmed all but the ongoing threads...

Kent

> SSH server configuration model?

This is my hope, so as to limit the scope of this document.

> come with their own integrated SSH server. Does this affect the data

I think JUNOS is an example where the NC server runs "behind an SSH
server", but it's not really "behind" so much as a fork/exec of an
sshd process running the "netconf" subsystem (i.e., the NC server).
Is this what you meant?

Regardless, I don't see a need to change either the ietf-netconf-server
or ietf-ssh-server data models to support either the fork/exec or
link-to-library implementation strategies.  Do you?

> So you are saying I guess this is the direction you see this to evolve.

Yes, I'm hoping to not increase the scope of this draft.  I do see it
as a possible future item to define a concrete SSH server data model.
That effort would entail evaluating various implementations to ensure
it captures the most commonly used bits in the base model, and using
features for the less-used parts.

> traditionally all do their own little soup. If the later, then this
> is likely how it works in practice. So the security WGs actually

I agree with this line of thinking, but it belongs with the discussion
regarding factoring the identities out.  Also, Gary responded separately 
about defining foo-ref typedefs.  So, let's let those threads carry this
conversation.

> remove the text during the final stages of the process.

I wouldn't want to punt this to the RFC Editor.  Perhaps we need more
opinions.  I actually agree with what you write, but I'm trying to be
faithful to the guidelines [1] where it says:

  Each specification that defines one or more YANG modules 
  MUST contain a section that discusses security considerations
  relevant to those modules. This section MUST be patterned
  after the latest approved template

[1] https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

While looking at these guidelines, I also think that this line
at the end is wrong: 

  Note: [RFC5246], [RFC6241], [RFC6242], [RFC6536], and 
  [RFC8040] must be "normative references".

>> Why should there be, isn't that a protocol-specific issue?  For
>> instance, per comments from before, the ietf-netconf-client and
>> ietf-restconf-client models add 'must' statements asserting
>> client-authentication is configured. Is this something that
>> should be mentioned in Security Considerations?
>

Sorry, I misspoke before.  The 'must' statements were used elsewhere.
For section 2, /ietf-ssh-client:ssh-client/client-auth/auth-type is
set to mandatory true.  So, in this case, client-auth is always 
configured, and your original concern unwarranted?

> a specific certificate in general is not true.

I see.  You're right, the ietf-tls-server grouping currently
does not configure SNI.  I know Gary put out a proposal that
you said might work, but I don't understand yet if a change
in ietf-tls-server is needed, or it's just how ietf-tls-server
is used...

> purposes but then also pretty clearly the TLS groupings are not

Thinking about this some more, it seems my previous response
wasn't on target.  This isn't about what auth-credentials the
client passes, so much as how the client indicates the server
it wants to connect to in its client hello message.  It 
seems like something to configure SNI should be added to 
ietf-tls-client, how about this?

  +-- server-name-indication
    +-- server-name* [name-type]
      +-- name-type  enumeration (e.g., 'hostname')
      +-- name-value anydata     (e.g., foobar.example.com)      

And likewise to ietf-tls-server, though I have less idea 
how to do it (suggestions welcome!)  or, like mentioned above,
maybe it's just how ietf-tls-server is used.

> So the server magically picks one. This may be OK for the TLS
> spec to say, not sure this is sufficient for a configuration spec.

Do you want the configuration spec to have a pointer to this part of
the TLS spec?

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Aug 2017 11:27:17 +0200

> link-to-library implementation strategies.  Do you?

Well, if your server is running as a subsystem of your regular SSH
daemon, then I think your SSH daemon configuration and your NETCONF
specific SSH configuration are essentially the same, no? Or more
precisely, you have an SSH daemon configuration plus a statement that
enables NETCONF as a subsystem, but you do not have a NETCONF specific
SSH configuration.

> features for the less-used parts.
 
Yes, this should not be in this draft but at least it should be clear
how this all would integrate, see my comment above.

> configured, and your original concern unwarranted?
 
Likely.
 
> maybe it's just how ietf-tls-server is used.

On the server side, based on the SNI received, you have to pick the
right key and certificate. So there needs to be some mapping.

> Do you want the configuration spec to have a pointer to this part of

Well, the TLS spec text does not help me to configure this such that I
get the right certificate selected for the SNI presented...

/js

---

From: Kent Watsen <[email-masked]>
Date: Mon, 21 Aug 2017 23:09:27 +0000

Hi Juergen,

> enables NETCONF as a subsystem, but you do not have a NETCONF specific

Not exactly.  There's SSH listening on port 22 and then there is SSH 
listening on port 830.  When listening on 830, it can be a separate 
instance of `sshd` and given unique startup parameters (e.g., the 
sshd_config file).  It is not expected that this configuration 
(ietf-netconf-server) would ever influence the SSH listening on
port 22.

Back to if the implementation strategy can affects the data model, my 
assertion is that the startup parameters are equally applicable, whether
using the fork/exec (e.g., instances of `sshd`) or the link-to-library 
(e.g., a python script), and therefore I don't think the implementation
strategy affects the data model.

> how this all would integrate, see my comment above.

Yup, not in this draft.  Your comment above is still being discussed...

>>       +-- name-value anydata     (e.g., foobar.example.com)      

Second guessing myself here, does this really need to be configuration
or is the client-side of SNI just a function of how the code works?

> right key and certificate. So there needs to be some mapping.

hmmm, see below...

> get the right certificate selected for the SNI presented...

Peaking at TLS 1.3, draft-ietf-tls-tls13-21#section-4.4.2.2 says:

   -  The "server_name" and "certificate_authorities" extensions
      [RFC6066] are used to *guide certificate selection*.

and in S4.2.4 it says:

   The "trusted_ca_keys" extension, which serves a similar purpose
   [RFC6066], but is more complicated, is not used in TLS 1.3 (although
   it may appear in ClientHello messages from clients which are offering
   prior versions of TLS).

So, there's at least 3 different ways that the server can go about
selecting which certificates it sends.  To me, this again seems like
something maybe the server's code does internally - e.g., it sifts
through all the certs it has (i.e. list certificate in the YANG model),
sending the subset matching protocol-level criteria.  Do you know?

Peaking at NGINX config, it seems to have a config like:

  +--- server* [ <not sure what the key might be> ]
    +--- listen inet:port    // 443
    +--- server_name string  // example.com
    +--- root        string  // /usr/share/nginx/www
    +--- ssl         Boolean // on
    +--- ssl_certificate     // /etc/nginx/ssl/example.org/server.crt;
    +--- ssl_certificate_key // /etc/nginx/ssl/example.org/server.key;

Note that the TLS-part of the config has been splayed across the
app-specific config.  By contrast, the groupings we have now are more
for a single SSL host (not virtual hosting).  We could add 'sni-to-name'
mapping structures, but we it be helpful to complex TLS apps like NGINX?

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Aug 2017 08:22:03 +0200

> (ietf-netconf-server) would ever influence the SSH listening on

So are you running a separate SSH server just for NETCONF or not? I am
not asking about 'it _can_ be given unique parameters'.
 
> strategy affects the data model.

The question is whether there is a separate SSH daemon for NETCONF or
NETCONF is just hooked up the SSH daemon also used for other services.
I think this does make a difference, no?

> or is the client-side of SNI just a function of how the code works?

It is the server side that matters I think. 
 
> mapping structures, but we it be helpful to complex TLS apps like NGINX?

I think the key here is server_name as this allows nginx to multiplex
incoming connections to the "right" list instance, i.e., I can have
multiple server configured to listen on the same port and the TLS SNI
indication provides a hint which list instance is used and this
implies the correct security parameters.

/js