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

[Daniel Kahn Gillmor <[e-mail]>]

Hi Victor--

On 10/24/2014 11:54 AM, Viktor Dukhovni wrote:
> I am not familiar with any TLS policy pinning capabilities in Exim,
> Postfix, Sendmail or Qmail.

I didn't say "pinning", but "keeping state", which may or may not
include pinning.  postfix's sending MTA at least keeps track of whether
a given destination is considered "unavailable", see for example the
counts tracked and applied by
default_destination_concurrency_failed_cohort_limit.

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

To be clear: if the remote peer appears to offer STARTTLS in EHLO, and
the local system invokes it but the TLS handshake fails/is aborted, then
the local system tries again without doing STARTTLS even though it is
offered by the peer.  is this right?  or does a TLS handshake failure
count as a complete transmission failure?  if it's a transmission
failure comparable to a TCP RST, and the message is re-queued for later,
what is tried on the future reconnection?  even if it just directly
retries in the clear, this is a "fallback dance" of a sort.

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

Yes, it would be simpler to just require TLS, but we're already past
that point if we're prioritizing deliverability over security while
trying to provide some security anyway.

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

As does simply not allowing RC4.  If we're taking measures to
accommodate broken/out-of-date/poorly-implemented peers, it's worth
thinking about how to scope those accommodations to have minimal
negative effect on better-implemented and more-capable peers, as well as
on how to work around specific forms of misconfiguration that happen to
be prevalent.

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

It is actually not browser behavior.  Browsers today appear to fall back
based on the TLS version (see the FALLBACK_SCSV discussion here), but
not on ciphersuite choices or other features.  Popular browsers are in
the process of working up the courage to not to fall back to SSLv3
anymore, fwiw.  These are different modes of fallback operation than
we've been discussing, and they are distinct (and have different goals
and behaviors) from any sort of OS logic (they refuse to fall back to
cleartext, among other things).

TLS as a protocol is specified such that correct peers should never need
to do any kind of fallback dance, even if their implementations support
different versions.  Browsers layer in a fallback dance on top of TLS
(which sometimes makes bugs like POODLE exploitable) because they (like
MTAs) also value connectivity at least as much as security.

But a browser fallback dance and an MTA fallback dance are different,
and have subtly different features.

Other TLS applications (like Submission or IMAPS) have no fallback dance
at all, because of the nature of the pre-established relationship
between communication partners).

Perhaps the argument is that the MTA fallback dance, since it can be
forced ultimately to cleartext by a sufficiently motivated active
attacker anyway, should be *simpler* than the browser fallback dance,
and shouldn't make as many accommodations or require as much state and
complexity to implement.  I'm not sure i buy it, but if that's the
argument, it's worth making it explicitly.

Regards,

	--dkg