Re: [TLS] SNI as authorization token?

Thanks Martin, Rob.

Funnily enough, my draft ballot position (even before your note) contains:

    I'm extremely reluctant to suggest using SNI in this manner (as an
    impromptu authorization bearer token, akin to port knocking).

Since you got your replies in while I was taking an interrupt for something
else, I can relay the tentative suggestion to remove the whole appendix as well.

-Ben

On Wed, May 05, 2021 at 12:57:03PM +1000, Martin Thomson wrote:
> 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.com@dmarc.ietf.org> wrote:
> > > Hi all,
> > > 
> > > I'm reviewing draft-ietf-dprive-xfr-over-tls for this week's IESG telechat, and
> > > in https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dprive-xfr-over-tls-11*appendix-A.3__;Iw!!GjvTz_vk!Ay4HBe8M-L8oJtejnDhdK4oRwRyfeHdsZ7fbNfWtTZR-Jzifm-McY2xk_4gN1g$ 
> > > 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ay4HBe8M-L8oJtejnDhdK4oRwRyfeHdsZ7fbNfWtTZR-Jzifm-McY2wG6e-TtQ$ 
> > 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ay4HBe8M-L8oJtejnDhdK4oRwRyfeHdsZ7fbNfWtTZR-Jzifm-McY2wG6e-TtQ$ 