IETF Logo Mail Archive

Re: [TLS] SNI as authorization token?

Martin Thomson <mt@lowentropy.net> Wed, 05 May 2021 02:57 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E0C3A20C0 for <tls@ietfa.amsl.com>; Tue, 4 May 2021 19:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=gsJAsvYY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ISx62jKn
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kayRCvtoQ_67 for <tls@ietfa.amsl.com>; Tue, 4 May 2021 19:57:23 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9DF3A20C2 for <tls@ietf.org>; Tue, 4 May 2021 19:57:23 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 617A45C00AC for <tls@ietf.org>; Tue, 4 May 2021 22:57:22 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 04 May 2021 22:57:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=zbHEYJYV3wplDbzlW311L5BDJozLGCw 77T7lHQTjlqw=; b=gsJAsvYYDR1SGnfioHi+bkN7Lkizj5EtXqswmTGb1h+4Hng Q0wU5eipRNuouoev4YWPFYXssNPO5jU1EAzx4fmxp5SQrg6SLq9osagBRxG7yVK7 1+Cl/4j+ELBxCdJ+bxSuXUzmQlc+M8N9H4NnZ0U4gEqpoDPgGzruZ5J1bxLEC8gK G651NKe0bbM6dEYpbY9l+r3irp5dbAPY8JIfsLaZrcf8p6lMk9zwZTvWXCzvd8U2 d/hJdh7OKzpZDv6zGWQ1T23fl+BRdc+9X0YnVtACAvv4t0avqS4XLhTnFFZNPULy dNGi6mrMrWGiOVkDTf0WHMKM0Q4CkXYHiLicgtQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=zbHEYJ YV3wplDbzlW311L5BDJozLGCw77T7lHQTjlqw=; b=ISx62jKnRy6LT01bcEdBzJ e2kMR0Kz1HTfpKDN+EivS48Nkzep6Wba6nseW0AA/RDj7seqcPh5qdV4tvZ7sDYC aKhYFWf2G/yjCkxhoVOnVtZ+mtJ9fLXVIkiUWvM5QVr7JWdK24rCg/ZWqrAYYeIZ 3MWtbfCZ3shTGS4SmptwQuZWEBT+w1sGnsPx4ONitj9cjU2Xqk0IZTlCc7pKDuDa 9mUy1smRsU56HBDG0wmgdcFpLZapYJBoRKVu9kxDE6OO/IrzORlCJXVNRfQ1LQXN Niq6vLZuTTV0fJoKxmFoRrcOYnupZM+8Du9YipciFl3mR4+tDwQakF90jRXWN8tA ==
X-ME-Sender: <xms:kQmSYBiLQX9rFuRwUdc8fYXjw1gVJ2_4XfP7M6Q47xOfIthgFsgfKw> <xme:kQmSYGDl9WPU5x6NHn_PSY7xcInYYKdM4W-z4pIQqf3bMVaWNlnqE6cjVfyKb3f50 8YtUEFOSxkK4fbLgLY>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefjedgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeeijefhvddvgeeivdekje ekgffhheekhfeltdelieduhfduudekgfetgfdukeefveenucffohhmrghinhepihgvthhf rdhorhhgpdegtdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:kQmSYBFCpyd92AZqwv2Gx2YwT70lc0oFkpx_ZZN4R0ppTgOoend9qw> <xmx:kQmSYGTTIRKywITWqI-H8QlOrL7Ky5bEwu4P_FJoh7J4b1LHB9xoGw> <xmx:kQmSYOydxvCIfgC6gWG5MI1ItysxndRKJUpRSZHNRzasT_iEvm2tGg> <xmx:kgmSYN9An6un-mSxcxv-CvDnEhD4kQj_40qHAOHMS3KiQHFs40h13Q>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id E30814E00C7; Tue, 4 May 2021 22:57:21 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-442-g5daca166b9-fm-20210428.001-g5daca166
Mime-Version: 1.0
Message-Id: <4608c355-71f5-4481-9551-49c5b150ded8@www.fastmail.com>
In-Reply-To: <CAChr6SwMPJ0k=d7SiNreOSBMsagmN55yYjqmr5d42egA9qHOGQ@mail.gmail.com>
References: <20210504232015.GO25665@akamai.com> <CAChr6SwMPJ0k=d7SiNreOSBMsagmN55yYjqmr5d42egA9qHOGQ@mail.gmail.com>
Date: Wed, 05 May 2021 12:57:03 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xTwSwUVCHMBo_XjJ-QhVG3ONsjs>
Subject: Re: [TLS] SNI as authorization token?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2021 02:57:27 -0000

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://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
>

v2.14.0 | Report a Bug | By Email