Subject: [TLS] SNI as authorization token?

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 4 May 2021 16:20:16 -0700

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?

Thanks,

Ben

---

From: Rob Sayre <[email-masked]>
Date: Tue, 4 May 2021 16:30:08 -0700

On Tue, May 4, 2021 at 4:20 PM Benjamin Kaduk <bkaduk=
[email-masked]> wrote:

> in
> https://datatracker.ietf.org/doc/html/draft-ietf-dprive-xfr-over-tls-11#appendix-A.3

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

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 05 May 2021 12:57:03 +1000

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=[email-masked]> wrote:
> > Hi all,
> > 
> 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
> [email-masked] <mailto:TLS%40ietf.org>
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 4 May 2021 21:06:14 -0700

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:
> > > 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$ 
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ay4HBe8M-L8oJtejnDhdK4oRwRyfeHdsZ7fbNfWtTZR-Jzifm-McY2wG6e-TtQ$ 
> > 
> 
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ay4HBe8M-L8oJtejnDhdK4oRwRyfeHdsZ7fbNfWtTZR-Jzifm-McY2wG6e-TtQ$

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 5 May 2021 13:24:55 +0000

ACME had SNI-based challenges, which evolved into ALPN and became RFC 8737