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

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

Hi Victor--

On 10/24/2014 10:12 AM, Viktor Dukhovni wrote:
> On Fri, Oct 24, 2014 at 10:01:23AM -0400, Daniel Kahn Gillmor wrote:
> 
>> arguably, there are many such "grossly-misconfigured peers" right now
>> with respect to RC4 (usually because of misguided attempts to protect
>> against BEAST, aiui).  These are servers that support something other
>> than RC4, but select RC4 if a client offers it (even if it was the
>> client's lowest priority).
> 
> [ Note I was responding to Stephen's side note about opportunistic
>   security, we're no longer discussing the language of the draft. ]

yes, agreed.  thanks for making this explicit.

> Indeed if RC4 were always selected for spurious reasons, then one
> might be wise to disable it.  We're not there yet,  so in practice
> opportunistic applications will not immediately change to adhere
> to the draft.

Yep, i understand.  We're not at "always" yet, though some systems (MTAs
as well as HTTP servers, iiuc) are indeed selecting RC4 for spurious
reasons.

>> So the safest OS approach in the context of a strongly-deprecated cipher
>> $WEAK_CIPHER, for a client that is willing to ultimately fall back to
>> cleartext would be, for any given peer P:
>>
>>  * connect to P and offer TLS without $WEAK_CIPHER
>>  * if that fails with "no cipher overlap", then:
>>     * reconnect to P and offer TLS with $WEAK_CIPHER
>>     * if that fails for any reason, then:
>>         * reconnect to P with cleartext.
> 
> That's too much code.  MTAs are not browsers, there are no complex
> multi-pass attempts to establish TLS.  TLS either happens or does
> not.  If the handshake fails, some will retry in cleartext, others
> will skip to the next MX host or defer the mail.
> 
> With MTAs the remote end often has connection rate limits, and may
> lower the "reputation" of clients that frequently disconnect without
> completing a delivery.
> 
>> This could probably be further improved by remembering which level of
>> fallback succeeded on previous attempts, and refusing to fallback further.
> 
> 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
 (b) MTAs don't keep state about their peers, so they can't remember
what they've tried

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

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.

But that doesn't mean that the proposed logic isn't ultimately a
sensible approach to try to advance confidentiality and integrity goals
without harming deliverability.

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.

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.

(this has the nice property "if you want your users to get their mail
faster, you should ensure that your MTA offers stronger security",
thereby tying together usability and security)

Perhaps this discussion might be better continued on UTA, sorry if it's
OT here.

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

Thanks for your work on opportunistic security, both here in the IETF
and on Postfix itself, Victor.  It's exciting to see someone leading the
way forward with this.

Regards,

	--dkg