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

Viktor Dukhovni <> Fri, 24 October 2014 15:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 28A941A00D6 for <>; Fri, 24 Oct 2014 08:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VYcJK5VKhMlu for <>; Fri, 24 Oct 2014 08:54:16 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C5CE1A1AA3 for <>; Fri, 24 Oct 2014 08:54:14 -0700 (PDT)
Received: by (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 <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

> 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".