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....@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$
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
