Re: [ietf-smtp] ALPN

Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Thu, 29 July 2021 06:39 UTC

Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1CF3A124F for <ietf-smtp@ietfa.amsl.com>; Wed, 28 Jul 2021 23:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no
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 WDLSY3CT1cyQ for <ietf-smtp@ietfa.amsl.com>; Wed, 28 Jul 2021 23:39:13 -0700 (PDT)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [144.76.73.169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7F33A124C for <ietf-smtp@ietf.org>; Wed, 28 Jul 2021 23:39:12 -0700 (PDT)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 3CC6CC0130; Thu, 29 Jul 2021 07:39:09 +0100 (IST)
Authentication-Results: stabil.gulbrandsen.priv.no; dmarc=none (p=none dis=none) header.from=gulbrandsen.priv.no
Authentication-Results: stabil.gulbrandsen.priv.no; spf=none smtp.mailfrom=arnt@gulbrandsen.priv.no
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1627540749; bh=AtpjGicmCviNIa6VO3N9gNVkYhM7teW3GVEYgVG67ho=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Tn36dLWYN4lcws5fO0zJ3qqsHoWmqyP0eQxL3ivb6tceR797spHOCcHzMJ0Q5C93Y YIyVI5Z6K6ml65G99s2/Qg8oa9oALL23Q33+nOEqiFKntQZBuW45Ur9f02wRTiFz95 pnC1oUE9VPEDjpAlq7ulNRnnFP7ItbiEZkcJNm7g=
Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1627540748-6369-14922/9/12; Thu, 29 Jul 2021 06:39:08 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: ietf-smtp@ietf.org
Date: Thu, 29 Jul 2021 08:39:08 +0200
Mime-Version: 1.0
Message-Id: <1e72f0b6-d71a-484b-a571-53564bf6a16b@gulbrandsen.priv.no>
In-Reply-To: <20210729044632.GA80094@kiel.esmtp.org>
References: <20210728172631.GA24560@kiel.esmtp.org> <20210729030741.0BDDB2548012@ary.qy> <20210729044632.GA80094@kiel.esmtp.org>
User-Agent: Trojita/0.7; Qt/5.11.3; xcb; Linux; Devuan GNU/Linux 3 (beowulf)
Content-Type: text/plain; charset="utf-8"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/_nDJwFV6T49zI82x84GCKbNxVE8>
Subject: Re: [ietf-smtp] ALPN
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jul 2021 06:39:18 -0000

On Thursday 29 July 2021 06:46:32 CEST, Claus Assmann wrote:
> On Wed, Jul 28, 2021, John Levine wrote:
>
>> I have trouble imagining an actual threat, and even more trouble imagning
>> one where an ALPN would make any difference.
>
> Isn't this what "ALPACA" is about?
> htttps://alpaca-attack.com/>

ALPN defends against that attack by making other ALPNs different from what 
code running on the VM inside a web browser requires.

In this case, we're talking about whether there is one different ALPN or 
four. Either case suffices to protect email servers from being involved in  
attacks against web browsers.

Four means that a malevolent server cannot fool code that expects to 
connect to an IMAP server into connecting to an SMTP server and revealing 
secrets (e.g. by sending an APPEND command). But IMAP clients don't run 
server-supplied code, and don't contain VMs that could protect against 
malevolent server-supplied code by checking ALPN.

I like having one ALPN identifier rather than four, since it requires a 
smaller change to email clients that share/reuse code for using TLS within 
different protocols,

Arnt