Re: [Uta] REQUIRETLS update

Jim Fenton <fenton@bluepopcorn.net> Wed, 07 December 2016 19:28 UTC

Return-Path: <fenton@bluepopcorn.net>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02274129A41 for <uta@ietfa.amsl.com>; Wed, 7 Dec 2016 11:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.897
X-Spam-Level:
X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
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 gGolIwRTDd8W for <uta@ietfa.amsl.com>; Wed, 7 Dec 2016 11:28:20 -0800 (PST)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 D024F1299FA for <uta@ietf.org>; Wed, 7 Dec 2016 11:28:20 -0800 (PST)
Received: from splunge.local (c-24-4-98-3.hsd1.ca.comcast.net [24.4.98.3]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id uB7JSIhL024478 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <uta@ietf.org>; Wed, 7 Dec 2016 11:28:20 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1481138900; bh=rzxns2dG+cD4mqUROCy+D6uBrht7xwgLcDaKwZs1Vzs=; h=Subject:To:References:From:Date:In-Reply-To; b=ePy4Wh54CBEFEby5wNrLmDzMHepL/ed0q5+Q9ZWZFhpUPUp7QV1GACPHe/QYQRyNy 4tNyHWseXKQlL7BXaGyjrm8J0h4z/QBuk/pLHHnl5GgjNNoXIr7qcRQwmDzM53dTue yZMJ/ta1CsA+uAqAbr4vRCpI4mrjogKoGDouUaC8=
To: uta@ietf.org
References: <f40d379d-6aca-30dc-19f7-ff159b08bc69@bluepopcorn.net> <20161207021907.GL13486@mournblade.imrryr.org>
From: Jim Fenton <fenton@bluepopcorn.net>
Message-ID: <6d8880fb-0369-1181-c3bd-0ac087481ea7@bluepopcorn.net>
Date: Wed, 07 Dec 2016 11:28:15 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <20161207021907.GL13486@mournblade.imrryr.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/rKTCMkoK6bLbhgmP7-1oi3CQBds>
Subject: Re: [Uta] REQUIRETLS update
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2016 19:28:22 -0000

On 12/6/16 6:19 PM, Viktor Dukhovni wrote:
> On Tue, Dec 06, 2016 at 04:30:32PM -0800, Jim Fenton wrote:
>
>> It has been a little while, so I thought it might be appropriate to give
>> the WG an update on the status of REQUIRETLS
>> (draft-fenton-smtp-require-tls-02).
> Is there any new thinking on supporting user signalling of TLS
> opt-out?  (Urgent, but non-sensitive message needs to get through
> despite DANE or STS policy that might otherwise hinder delivery
> when some operational snafu breaks the promised security features).
>
> I rather see opt-out as much more realistically useful than the
> converse covered by REQUIRETLS.  And I do still strongly believe
> that the same spec should cover both halves of this problem.
>
I haven't thought about this suggestion much further; I haven't heard
any further support for it.

As for usefulness, I tend to think of a (potentially) multi-hop
store-and-forward protocol like SMTP as being the wrong way to send an
urgent message in the first place. There are lots of operational snafus
that might break email entirely in such a way that this downgrade won't
recover from, so if someone has an urgent need to communicate, they need
to have an independent way to do it.

-Jim