IETF Logo Mail Archive

Re: [TLS] SNI as authorization token?

Benjamin Kaduk <bkaduk@akamai.com> Wed, 05 May 2021 04:06 UTC

Return-Path: <bkaduk@akamai.com>
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 621CD3A22FD for <tls@ietfa.amsl.com>; Tue, 4 May 2021 21:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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=akamai.com
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 yuC5cUPk-BjD for <tls@ietfa.amsl.com>; Tue, 4 May 2021 21:06:18 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B5A3A22FC for <tls@ietf.org>; Tue, 4 May 2021 21:06:18 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 14544W4M009457; Wed, 5 May 2021 05:06:16 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=oOsZCfBtusv8/Za9CVxtYxdk+xMlBT7OpB82Abab0jc=; b=MAZunP/GyQaOm0NsIlvdC7sfqoMOsVNovKw9KE2Bh7MdKV68ONrxPsxJIvoupg/c/XN7 2o3jmvqQzKubLp9GAB2VES8jJT/N9lu2Wrf94fg2oEDiv0eLAcyCpv87/B06U6r1QXtK vUQ/hqf2t65V+UaCroN+kdWZgNhWGb4V/pdX+GdUH9GaJ9oWtxU98CUIyjUxcqGJ75yo dz85ZcV4jXFF5lX3/sqXHlII9Nq8ypad0RJ+tllI7jpNHM2aFUU3Q6zcCZMlcaCuFca1 QuXyOSNejzDXf3mVsq6uvxgUpr97AoppiIj/UTm6uWC4QZfSl1eLJH/npdpB/hA8aaOg Pg==
Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 38bebkrqas-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 May 2021 05:06:16 +0100
Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 14544YBu028290; Wed, 5 May 2021 00:06:15 -0400
Received: from prod-mail-relay18.dfw02.corp.akamai.com ([172.27.165.172]) by prod-mail-ppoint7.akamai.com with ESMTP id 38bebh2r9s-1; Wed, 05 May 2021 00:06:15 -0400
Received: from akamai.com (unknown [172.19.16.134]) by prod-mail-relay18.dfw02.corp.akamai.com (Postfix) with ESMTP id 28157595; Wed, 5 May 2021 04:06:15 +0000 (GMT)
Date: Tue, 04 May 2021 21:06:14 -0700
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: tls@ietf.org
Message-ID: <20210505040613.GP25665@akamai.com>
References: <20210504232015.GO25665@akamai.com> <CAChr6SwMPJ0k=d7SiNreOSBMsagmN55yYjqmr5d42egA9qHOGQ@mail.gmail.com> <4608c355-71f5-4481-9551-49c5b150ded8@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4608c355-71f5-4481-9551-49c5b150ded8@www.fastmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-05_01:2021-05-04, 2021-05-05 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0 mlxlogscore=999 phishscore=0 adultscore=0 bulkscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2105050025
X-Proofpoint-GUID: xOLL-ni5dQRQMDL5BQ56ERM6y3MeTIlX
X-Proofpoint-ORIG-GUID: xOLL-ni5dQRQMDL5BQ56ERM6y3MeTIlX
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-05_01:2021-05-04, 2021-05-05 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 impostorscore=0 priorityscore=1501 spamscore=0 mlxscore=0 phishscore=0 mlxlogscore=937 suspectscore=0 clxscore=1015 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2105050025
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.33) smtp.mailfrom=bkaduk@akamai.com smtp.helo=prod-mail-ppoint7
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ncmjsBgQ7RfRqG5-ToD_DGmgdUg>
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 04:06:23 -0000

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$

v2.14.0 | Report a Bug | By Email