Re: [Uta] New Version Notification for draft-fenton-smtp-require-tls-03.txt
Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 04 March 2017 00:37 UTC
Return-Path: <ietf-dane@dukhovni.org>
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 770201294BA for <uta@ietfa.amsl.com>; Fri, 3 Mar 2017 16:37:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 rHKgMIhZsyf6 for <uta@ietfa.amsl.com>; Fri, 3 Mar 2017 16:37:28 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE6E127601 for <uta@ietf.org>; Fri, 3 Mar 2017 16:37:28 -0800 (PST)
Received: from [10.27.14.3] (mobile-166-171-184-226.mycingular.net [166.171.184.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 5C0A37A32D8 for <uta@ietf.org>; Sat, 4 Mar 2017 00:37:20 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <3f9308ab-d01d-71e9-be14-b9894601a416@bluepopcorn.net>
Date: Fri, 03 Mar 2017 19:36:58 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <E9189BFF-D1DE-4298-8301-457C392EB3EE@dukhovni.org>
References: <148705066595.22281.9383659754042012758.idtracker@ietfa.amsl.com> <3f9308ab-d01d-71e9-be14-b9894601a416@bluepopcorn.net>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/K6Ed02IpzFk2D8TUnIn1oXCrjZc>
Subject: Re: [Uta] New Version Notification for draft-fenton-smtp-require-tls-03.txt
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: uta@ietf.org
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: Sat, 04 Mar 2017 00:37:30 -0000
> On Feb 14, 2017, at 12:51 AM, Jim Fenton <fenton@bluepopcorn.net> wrote: > > A new version of I-D, draft-fenton-smtp-require-tls-03.txt > has been successfully submitted by Jim Fenton and posted to the > IETF repository. Review comments: === Abstract: The text starts: The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is prioritized over security. ... I do not think it is appropriate to say "not as useful as it might be". Unauthenticated opportunistic STARTTLS is *very* useful and effective in reducing opportunities for passive attacks. Indeed with ~84% of email protected via TLS: https://www.google.com/transparencyreport/saferemail/ opportunistic STARTTLS is more successful than HTTPS, which recent reports indicate protects ~50% of web site visits. Now of course it is fair and accurate to say that unauthenticated opportunistic SMTP STARTTLS alone offers only passive attack protection and that mechanisms such as RFC7672 DANE or the proposed STS are hop-by-hop MTA-to-MTA security protocols, which seek to strengthen "the network", but give no control to the user. So I see this draft as filling that gap. Therefore, I think it would be best to start with something that goes right to the point. A start in that direction might be: No existing IETF protocol gives an email user the means to express SMTP transport security policy beyond the user's initial interaction with the message submission agent (MSA). Any further SMTP relaying of the message from the MSA, often via multiple relay hops, to its final destination is subject only to the policy of the intermediate email relays. This specification provides a mechanism for a user to express an SMTP transport security preference, either to prioritize security, or, conversely, to prioritize delivery even when transport security is not available or appears to be compromised. The above likely has its own flaws, so feel free to borrow from it or ignore it as you see fit, but perhaps it serves to clarify the approach I'm suggesting. === 1. Introduction By default, TLS is used only upon mutual agreement (successful negotiation) of STARTTLS between the client and server; if this is not possible, the message is sent without transport encryption. Furthermore, it is common practice for the client to negotiate TLS even if the SMTP server's certificate fails to authenticate it. Here, I think the point is not that the client "negotiates TLS" even when authentication fails, but rather that *delivery* continues despite lack of authentication (a reference to RFC7435 may be appropriate here). It would certainly not be better (as sadly done by some MTAs) to abort the TLS handshake and deliver in the clear! So the last sentence should be rewritten. The second paragraph: Policy mechanisms such as DANE [RFC7672] and SMTP STS [I-D.ietf-uta-mta-sts] may impose requirements for the use of TLS for email destined for some domains. However, such policies do not allow the sender to specify which messages are more sensitive and require transport-level encryption, and which ones are urgent and ought to be relayed even if TLS cannot be negotiated successfully. is much closer to the spirit of what I'm suggesting for the abstract, so it could be another basis for a new abstract, or text that connects the abstract to the introduction. The third paragraph reads: The default opportunistic nature of SMTP TLS enables several "on the wire" attacks on SMTP security between MTAs. These include passive eavesdropping on connections for which TLS is not used, interference in the SMTP protocol to prevent TLS from being negotiated (presumably followed by eavesdropping), and insertion of a man-in-the-middle attacker taking advantage of the lack of server authentication by the client. Attacks are more described in more detail in the Security Considerations section of this document. Here you're conflating opportunistic (RFC7435), with "unauthenticated" use-cases that are not downgrade-resistant. Keep in mind that DANE is still "opportunistic TLS", because authenticated delivery takes place only when the peer publishes TLSA records, and TLS is otherwise best effort. So DANE for SMTP is a downgrade-resistant, authenticated, but still opportunistic mechanism, and the same holds for the proposed STS. Downgrade attacks are considerably more difficult with DANE, and to a lesser degree with STS (which is weak on first contact, but provides similar defenses thereafter). === 2. The REQUIRETLS Service Extension What is optional per the paragraph: An optional parameter to the REQUIRETLS MAIL FROM option specifies the requirements for server authentication that MUST be used for any onward transmission of the following message. The parameter takes the form of either a single value or comma-separated list, separated from the REQUIRETLS option by a single "=" (equals-sign) character. If present, the parameter MUST take one or more of the following values: is optional to add "REQUIRETLS=..." to "MAIL FROM" or it optional to add "=..." with "REQUIRETLS"? The first sentence suggests the latter, but I don't think that makes sense. What follows immediately below that paragraph is IMNSHO an overly prescriptive disaster: o CHAIN - The certificate presented by the SMTP server MUST verify successfully in a trust chain leading to a certificate trusted by the SMTP client. The choice of trusted (root) certificates by the client is at their own discretion. The client MAY choose to use the certificate set maintained by the CA/B forum [citation needed] for this purpose. o DANE - The certificate presented by the SMTP server MUST verify succesfully using DANE as specified in RFC 7672 [RFC7672]. o DNSSEC - The server MUST confirm that any MX record or CNAME lookup used to locate the SMTP server must be DNSSEC [RFC4035] signed and valid. o NO - The SMTP client SHOULD attempt to send the message regardless of its ability to negotiate STARTTLS with the SMTP server, ignoring policy-based mechanisms, if any, asserted by the recipient domain. Nevertheless, the client MAY negotiate STARTTLS with the server if available. If the NO parameter is present, any other REQUIRETLS parameter MUST NOT be used. Setting aside the "NO" case, the remaining options are MUCH too precise. The client should at most be able to specify: * ENCRYPT: must negotiate STARTTLS, but perhaps not authenticated * SECURE: must negotiate STARTTLS *and* authenticate the peer via DANE, STS or local policy that provides active-attack resistance for the nexthop destination. I don't see anyone using "CHAIN", "DANE", "DNSSEC" or being able to explain these to users. I'll stop here for now, because the rest of the document is moot if this issue cannot be resolved. -- Viktor.
- [Uta] Fwd: New Version Notification for draft-fen… Jim Fenton
- Re: [Uta] New Version Notification for draft-fent… Viktor Dukhovni
- Re: [Uta] New Version Notification for draft-fent… Jim Fenton