I agree with Rob here. Removing the appendix would be best. It's true that some servers have special names, but that is for operational reasons. Pretending that something you put on the wire in the clear is a security mechanism would be dishonest.
This reminds me of port knocking. It's not an effective defense against a motivated attacker, but people deploy it anyway. If the IETF were to recommend that, then it would have to come with stronger safeguards than "maybe ECH will make this secure one day". On Wed, May 5, 2021, at 09:30, Rob Sayre wrote: > On Tue, May 4, 2021 at 4:20 PM Benjamin Kaduk > <bkaduk=40akamai....@dmarc.ietf.org> wrote: > > Hi all, > > > > I'm reviewing draft-ietf-dprive-xfr-over-tls for this week's IESG telechat, > > and > > in > > https://datatracker.ietf.org/doc/html/draft-ietf-dprive-xfr-over-tls-11#appendix-A.3 > > it seems to suggest that a TLS server might only choose to allow > > connections that > > include a specific (secret-ish) SNI value. Given that the "as above" > > listed "con" > > seems to indicate that there are no relevant implementations of this > > functionality, > > I plan to push back on its inclusion in the document; a PSK mode (with cert, > > per RFC 8773) would seem to be universally superior. > > > > Am I correct to do so? Do we know of any cases where the SNI value is being > > (ab)used as an authorization token in this manner? > > It certainly happens with subdomains. I'd recommend removing that > entire appendix, though. It seems like generic TLS / DoS advice that > doesn't really belong in the document. > > thanks, > Rob > > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS%40ietf.org> > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
