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
- [ietf-smtp] ALPN Jeremy Harris
- Re: [ietf-smtp] ALPN John Levine
- Re: [ietf-smtp] ALPN Viktor Dukhovni
- Re: [ietf-smtp] ALPN Claus Assmann
- Re: [ietf-smtp] ALPN John Levine
- Re: [ietf-smtp] ALPN Alexey Melnikov
- Re: [ietf-smtp] ALPN Jeremy Harris
- Re: [ietf-smtp] ALPN Claus Assmann
- Re: [ietf-smtp] ALPN John R Levine
- Re: [ietf-smtp] ALPN John Levine
- Re: [ietf-smtp] ALPN Claus Assmann
- Re: [ietf-smtp] ALPN Arnt Gulbrandsen
- Re: [ietf-smtp] ALPN Claus Assmann
- Re: [ietf-smtp] ALPN John Levine
- Re: [ietf-smtp] ALPN Viktor Dukhovni
- Re: [ietf-smtp] ALPN Ned Freed