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

[Viktor Dukhovni <[e-mail]>]

On Fri, Oct 24, 2014 at 12:50:18PM -0400, Daniel Kahn Gillmor 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.  

I meant pinning in a broad sense that includes storing TLS
capabilities.

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

[ Deep-dives into Postfix designs here are not going to be productive
  direction.  I will not respond to further attempts to sell me on the
  merits of complex schemes for MTA. ]

As the instigator of that algorithm, I am well aware of its design.
This is not persistent state.  It is flushed as soon as there are
there no more messages in the queue for the destination in question.
For dead destinations the zombie state lives for a short time in
the queue manager's memory until a timer expires.

This does not leave any room for persisting state beyond the lifetime
of a stream of back to back messages.  Nor does the queue manager
store any state about MX hosts, that would be up the SMTP delivery
agent.

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

It is implementation dependent.  Postfix will typically try in the
clear, with some of the most recent versions typically after the
message is tried and fails at any other MX hosts.  Sendmail does
not retry in the clear after STARTTLS fails, the message stays in
queue unless some other MX host is less broken.

> or does a TLS handshake failure
> count as a complete transmission failure? 

Yes in Sendmail.

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

STARTTLS again with Sendmail.  With Postfix generally STARTTLS,
but on a second failure by default cleartext in all versions.  We're
thinking of adding controls that optionally disable this fallback and
allow users to chooose the Sendmail behaviour.

> even if it just directly
> retries in the clear, this is a "fallback dance" of a sort.

I already said there's fallback (to cleartext from TLS).  There is
not and will not be cipher suite or protocol fallback.

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

The fallback mechanism will be kept as simple as possible.  That
means no multiple attempts with different variants of the TLS
settings.  If that TLS handshake fails, mail is sent in the clear
or not sent.  If some TLS feature choices are error prone, they
are not used.

Thus, for example, RC4 will not by default be disabled for some
time.  If TLS 1.3 will prove to have interop issues, it will be
initially disabled until these are resolved.  And so on.

Opportunistic TLS will avoid bleeding-edge settings, and will stick
to what is known to work reliably (be it "less optimally" in some
sense).

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

This non-problem is not worth the time we're spending on it.

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

That's a good part of the argument, opportunistic TLS is icing on
the cake.  Mostly good neighbourliness for the benefit of the
ecosystem rather than a specific desire to protect a paricular
message.  Therefore, the mechanisms used need to be simple and
reliable.

With opportunistic DANE TLS, when usable TLSA RRs are published,
some SMTP clients allow remote servers to signal a requirement for
stronger protection (in a downgrade-resistant manner).  Here the
picture changes, fallback is not enabled by default (to either
cleartext or unauthenticated encryption) and stronger ciphersuites
are required.  In this case RC4 might reasonably be excluded for
such peers.  It am not expecting too many RC4-only peers with
published TLSA records.

We should stop spamming the list...  This is largely off topic
here.

-- 
	VIktor.