Re: [TLS] Deployment ... Re: This working group has failed

Nico Williams <nico@cryptonector.com> Wed, 27 November 2013 02:01 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440461AE02A for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 18:01:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 iVmgO6RMcRu3 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 18:01:20 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB071AC3DA for <tls@ietf.org>; Tue, 26 Nov 2013 18:01:20 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id E61D4678057; Tue, 26 Nov 2013 18:01:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=KbjNQzmyrmtR+5 0yv0BDjRzRz/o=; b=byUatNkW0WSrIwM4VzkE9JpJxFQFL6bVD81Wulq9GUUw1h K8pCofwqYO00qxqbjUjVhz8VvCbWAdYLeHSWaplMJKfYWumYT/umJP8rKXc2Ci/k ld//sMWlMmlNG8WdqXjR+7AG8iO90J0GwSB84yGpEoLnmYQcOxPEuxrMenGAY=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id 92B47678063; Tue, 26 Nov 2013 18:01:19 -0800 (PST)
Date: Tue, 26 Nov 2013 20:01:18 -0600
From: Nico Williams <nico@cryptonector.com>
To: Andy Lutomirski <luto@amacapital.net>
Message-ID: <20131127020116.GO21240@localhost>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com> <CAK3OfOh05SMBJNQ-Spd-K9kYGQuriagayskOzJmQm27nZfdpow@mail.gmail.com> <CALCETrV-6nQfq_yMU5QSNw4coY3hbziUipE8xwLKn5R_xE6t0w@mail.gmail.com> <CAK3OfOgGtLtwfsPxLAsBE1sMB8gH4BOEfHAocgBK7WVALWnpTQ@mail.gmail.com> <CALCETrXC=MSUYaRb4C1OuFBLHkwfUiftntBpw7sO5ZBGUzvqqA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CALCETrXC=MSUYaRb4C1OuFBLHkwfUiftntBpw7sO5ZBGUzvqqA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "tls@ietf.org" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Nov 2013 02:01:21 -0000

On Tue, Nov 26, 2013 at 05:51:14PM -0800, Andy Lutomirski wrote:
> On Tue, Nov 26, 2013 at 5:46 PM, Nico Williams <nico@cryptonector.com> wrote:
> > I'm  talking about SMTP between MTAs, not SUBMIT (SMTP between MUAs
> > and MSAs).  With that clarification:
> >
> > Because it's more important that e-mail flow and be delivered than
> > that it be hop-by-hop secure.
> 
> Then let those programs use some kind of hack to turn off
> authentication if they really know what they're doing.  (SMTP isn't
> hop-by-hop secure, regardless of TLS.)

Exactly.  It has to be possible to turn off what you said must not be
possible to turn off.

> Nearly the entire web works by sending plain usernames and passwords
> over TLS, for better or for worse.

I'm aware, as aware as anybody else.  But here we were talking about
your outgoing mail server... that happens to use the same credentials
for mail submission as for all related web services, which is why it's
so critical that for *submission* TLS be used properly.  But for mail
*transfer* (between MTAs) it's generally more critical that mail get
through than that it do so securely.

Nico
--