Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 24 October 2014 15:54 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 28A941A00D6 for <tls@ietfa.amsl.com>; Fri, 24 Oct 2014 08:54:18 -0700 (PDT)
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
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 VYcJK5VKhMlu for <tls@ietfa.amsl.com>; Fri, 24 Oct 2014 08:54:16 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5CE1A1AA3 for <tls@ietf.org>; Fri, 24 Oct 2014 08:54:14 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 846492AB04A; Fri, 24 Oct 2014 15:54:07 +0000 (UTC)
Date: Fri, 24 Oct 2014 15:54:07 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20141024155407.GO19158@mournblade.imrryr.org>
References: <CAO7N=i3gC=+qcgHU=aMKtRyT7tZV5fm=9gJii-=yOpcNECOEvA@mail.gmail.com> <20141022175238.GF19158@mournblade.imrryr.org> <544837FD.202@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C71D3AF651E4@USMBX1.msg.corp.akamai.com> <5449A667.9040105@cs.tcd.ie> <20141024133728.GI19158@mournblade.imrryr.org> <544A5BB3.4000506@fifthhorseman.net> <20141024141215.GL19158@mournblade.imrryr.org> <544A680F.4080307@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <544A680F.4080307@fifthhorseman.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vO9AooMGwYG5Bnrt9K1DpGAsttY
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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: Fri, 24 Oct 2014 15:54:18 -0000

On Fri, Oct 24, 2014 at 10:54:07AM -0400, Daniel Kahn Gillmor wrote:

> > Sorry, MTAs don't maintain SQLite databases with peer history.
> > There is no interactive user to override stale pinned information.
> 
> In the paragraphs above, you seem to be claiming both of:
> 
>  (a) MTAs keep state about their peers, so we can't do retries, and

Receiving anti-spam engines that track client "reputations" do.
Sending MTAs do not.

>  (b) MTAs don't keep state about their peers, so they can't remember
> what they've tried

Correct.  Asymmetry between client and server.

> My understanding as an MTA operator, is that MTAs *do* keep state about
> their peers, and have (sometimes complex) logic about delivery choices,
> including on a per-destination or per-peer basis.  Whether that state is
> an an SQLite database or not, i don't really care.

I am not familiar with any TLS policy pinning capabilities in Exim,
Postfix, Sendmail or Qmail.

> I agree that it's all "too much code", and i'd love to have a nice
> simple clean TLS-only (and good-ciphers-only) MTA that has no fallback
> logic.  But that's not going to cut it if we want to interop in today's
> world, and if we prioritize delivery over confidentiality and integrity
> (which i understand is the traditional prioritization for MTA operators,
> and i do it myself).

Unless this WG goes out of its way to break opportunistic TLS, it
is working just fine today. :-)  None of the MTAs listed above have
multi-stage TLS fallback.  TLS either works out of the box or is
not used (cleartext fallback or transmission failure).

> I also understand that suggesting this behavior without a patch can be
> frustrating to MTA developers -- i'm sorry that i don't have time to
> produce such a patch for Postfix now.

No problem, we would not accept the patch anyway.  Code complexity
leads to bugs.

> If we take the fallback approaches described above, and each fallback
> incurs a small delay, to avoid the peer reputation rejection scenarios,
> then mail being delivered to RC4-only peers would be minorly delayed
> upon first delivery, and mail being delivered to cleartext-only peers
> would be doubly delayed for first delivery.

Cleartext fallback is much simpler, and the problem is non-existent.
Simply allowing RC4 avoids the need for all the complex code you
suggest.

> You could also build in a decay of recorded peer state, so that messages
> would continue to retry with the best-known level of security for a
> given peer, but would eventually fall-back to weaker fallbacks before
> discarding the messages as non-deliverable.  In the event of a mail
> server that somehow loses better-than-RC4 ciphers or regresses to
> non-STARTTLS entirely, messages to that mailserver would be delayed but
> not lost.

Did I mention that code complexity leads to bugs?

> > Browser analogies and strategies work poorly or not at all when
> > misapplied to SMTP.
> 
> I wrote the entire original message thinking specifically about SMTP, fwiw.

And your approach is essentially a transplant of browser behaviour.
"This is not your browser's TLS".

-- 
	Viktor.