re: SNI, I would rephrase this, as I don't think it's required to use SNI. In some sense, SNI is just a routing concept (setting aside TLS1.3 encrypted SNI which breaks all of this).

re: mTLS, I might rephrase this slightly, as the way this is written will be contentious with some people. There is a set of people that think mTLS is too complicated and per-request (signing, etc. like JWT) is a better way to handle mutual authentication. I think mTLS is one way of doing this, but it would be good to rephrase slightly and potentially link to some of the per-request options such as JWT/Oauth/etc.

so re SNI, my understanding is that it prevents a type of spoofing - ie valid certs for wrong server (maybe this is wrong).

ill remove this/related advice and try to clarify what is written about it...

re mTLS - got it (i think) - ill make the warning about mutual authentication and encryption, and suggest this as a way to address those problems

so re SNI, my understanding is that it prevents a type of spoofing - ie valid certs for wrong server (maybe this is wrong).

yep, from further testing, this is wrong.

sni "allows" multiple domains to be served at same ip with different certs. I guess browsers just automatically use the dns name here.

From envoy configuration pov i guess the advice is still that its best to put the dns of upstream in tls cluster config

Im less clear how important it is to include in sec section, but ill try and reword and we can figure what/whether to include

Per above, SNI is about routing, not about security. It's actually not secure at all (until encrypted SNI in TLS 1.3). Can you check this around the doc and update/rephrase as needed?

so i get its called routing but my understanding is that it just "addresses" the other side with an "sni" name

certainly in my testing, dns had no bearing here - as long as the sni name matched what was in the match list (or there was no match list) then it worked

if there was a match list then the sni has to be set (dns also had no bearing in this case)

in terms of the title for this section - how about "Validating certificates with SNI" ?

i feel like we want to include sni here, and that it is sufficiently related to cert sec, but struggling to think how to word the section title

We can do it as a follow up, but I think it would be good to cross link here to other authentication and authorization concepts such as JWT/RBAC/OAUTH/etc.

cool, i have some other pending PRs around here, i reckon i can tack something on