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

[Viktor Dukhovni <[e-mail]>]

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.