Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

Chris Newman <chris.newman@oracle.com> Fri, 25 March 2016 23:00 UTC

Return-Path: <chris.newman@oracle.com>
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 E635B12D56E for <uta@ietfa.amsl.com>; Fri, 25 Mar 2016 16:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 UvV3khNVv0JH for <uta@ietfa.amsl.com>; Fri, 25 Mar 2016 15:59:59 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 E20AB12D0FC for <uta@ietf.org>; Fri, 25 Mar 2016 15:59:59 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2PMxoV2032561 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Mar 2016 22:59:50 GMT
Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2PMxocp008137; Fri, 25 Mar 2016 22:59:50 GMT
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_yDKTn1euakFxZpXsPi8PEA)"
Received: from Nifty.local (unknown [10.145.239.63]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 8.0.0.0.0 64bit (built Mar 19 2015)) with ESMTPSA id <0O4M0057QAJOVO00@gotmail.us.oracle.com>; Fri, 25 Mar 2016 15:59:48 -0700 (PDT)
Date: Fri, 25 Mar 2016 15:59:42 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Jim Fenton <fenton@bluepopcorn.net>, uta@ietf.org
Message-id: <etPan.56f5c2e3.3a9019c6.1520@Nifty.local>
In-reply-to: <56F49E9B.2090403@bluepopcorn.net>
References: <56F49E9B.2090403@bluepopcorn.net>
X-Mailer: Airmail (351)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/jhrimCTqUBgHMB8fluonuGBhU7k>
Subject: Re: [Uta] REQUIRETLS: another SMTP TLS mechanism
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: Fri, 25 Mar 2016 23:00:02 -0000

On March 24, 2016 at 12:42:07 , Jim Fenton (fenton@bluepopcorn.net) wrote:
Not to distract from the STS discussion, but I thought I'd point out 
another approach to SMTP TLS 'encouragement' that I submitted a few 
weeks ago: draft-fenton-smtp-require-tls-01. There has been some 
discussion of this draft, primarily on the ietf-smtp mailing list and a 
little on the perpass list. 

REQUIRETLS is an SMTP service extension that allows an SMTP client to 
specify (via a MAIL FROM option) that a given message must be sent over 
a TLS protected session with specified security characteristics. Options 
allow the specification of allowable methods of server certificate 
verification, including web-PKI and DANE. In advertising its support for 
REQUIRETLS, the SMTP server is promising to honor that requirement. 

The idea here is that REQUIRETLS allows the SMTP client to override the 
default "deliver even if you can't do it securely" behavior of SMTP. The 
philosophy is that the sender of the message (SMTP client) is in the 
best position to know if a given message should only be sent via TLS, 
either based on some information it has about the sensitivity of the 
message or based on the client's local policy. 

I plan on giving a short talk on REQUIRETLS (remotely) at the BA UTA 
meeting. Questions or comments are of course welcome, either here or on 
ietf-smtp. 
Having a protocol that allows a client to request that a particular SMTP security policy be applied to all hops is an interesting idea. However, I consider it important that we have a single extensible security policy model and syntax if possible. Can you change your proposal to reference the security policy model and syntax in DEEP (which includes extensibility)? If not, can you propose changes to DEEP that would help align these proposals?

I’d like to avoid having different ways to specify SMTP security policy in different places (syntax variations are annoying, semantic variations are a concern).

  https://tools.ietf.org/html/draft-ietf-uta-email-deep-04

		- Chris