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

From: Ryan Carboni <[email-masked]>
Date: Wed, 22 Oct 2014 10:28:54 -0700

>
> The main concern that I have with this approach is that attacks against
> RC4 will only get better and while the attacks may be currently impractical
> against HTTP cookies perhaps there are other usages where the problem may
> be greater.
>
> Pragmatically, implementers will do what is necessary to interoperate, so
> I think something along the lines of what Chris recommends below may be the
> best way forward.    I'm a bit reluctant to bring opportunistic security
> into the discussion at this point, but I think the rest is OK.
>
> Do folks think this is an acceptable way forward?
>
> Thanks,
>
> Joe

This is a common misconception. Cryptography isn't a linear effort. As
knowledge of cryptography improves through research, that knowledge is
applied through the design of future ciphers. This is why MD5 was easily
broken, but only after knowledge had improved. After theoretical attacks on
SHA-1 emerged, people used the trendline of how quickly md5 failed to
determine that SHA-256 will fall in about 5 to 15 years. Thus there was a
SHA-3 hash competition, but it turned out that the trendline failed, the
knowledge on which SHA-256 was built was superior to md5.

This is why SHA-256 will never have a malicious collision, and why RC4 will
never be broken. RC4 is a primitive design and Rivest got lucky in
designing a good cipher when knowledge of cryptography was so poor.
Preimaging the internal state of RC4 based on it's output will be
difficult, partly why the best attack from that direction is around 2^700.

RC4 shouldn't be used in new protocols much like md5, ChaCha8 128-bit
should probably replace RC4, but there aren't many fast ciphers currently
implemented in clients right now. And it will take years for
implementations to spread. It isn't practical to remove RC4 based on using
trendlines of past events when they don't apply in the same situation.

The number of possible permutations that could lead to a given RC4 output
is staggering, once again, the best attack on RC4's output is 2^700.
Attacks do not improve linearly, that is RC4 does not become 2^-10 less
secure each year.

On a minor note, after disabling RC4 and non-forward secrecy cipher suites,
I find my firefox browser negotiates Triple DES with servers with some old
set of cipher suites. I really do wish client side prioritization was
possible.

If you guys really want to disable RC4, why not disable Triple DES? It's
horribly insecure and is certainly "closer" to a break than RC4. It's 2^90
(despite a 168 bit key) at best, particularly with some precomputation
involved.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Oct 2014 17:52:39 +0000

On Wed, Oct 22, 2014 at 10:28:54AM -0700, Ryan Carboni wrote:

> never be broken.

Well, never is a long time, and it is already somewhat broken, in that
the bias in at least firt 256 bytes of output makes fixed plaintexts
transmitted repeatedly under varying keys vulnerable to recovery.

While I would prefer to see RC4 phased out more gradually, I do
not think we can claim that it has not been broken.

So I think that it would be nice if there was some wiggle-room for
opportunistic TLS.  As weak as RC4 might be, it is stronger than
cleartext.  And the published bias attacks don't apply to MTA to
MTA SMTP.  There is no (pairwise) fixed sensitive plaintext at a
fixed offset in every MTA to MTA email transaction.

I have no objections to banning RC4 for "strict" TLS use-cases.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Oct 2014 18:12:07 -0400

Attacks only get better when we learn more and RC4 will never be broken.

Did I summarize you accurately?

--
Principal Security Engineer, Akamai Technologies
IM: [email-masked]<mailto:[email-masked]> Twitter: RichSalz

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Oct 2014 00:04:29 +0100

Viktor,

> I have no objections to banning RC4 for "strict" TLS use-cases.

I think there is a significant difference between the security
(in particular confidentiality) one gets with good and dodgy
algorithms which is sufficient to argue that the OS design
pattern is inappropriate to use with such dodgy algs.

The problem is if the ciphertext is recorded and if the alg
in question is broken in the near future in a ciphertext-only
attack then the result was the same as no confidentiality,
and was (post-facto but still in fact) not "better" security,
as per the OS design pattern. The nearer the "near future" the
more this applies. One might even meet people who might
speculate that the "near future" for academic cryptographers
could be the recent past for some government cryptographers.

So, it is entirely consistent to both promote OS and deprecate
RC4 in TLS if the WG chairs declare this has rough consensus.

I guess questioning the proximity of the "near future" in the
above argument is reasonable, but if, as I believe, the crypto
folk all tell us RC4 is now definitely past its sell-by date
then it's time for an RFC that deprecates that so that the
sensible use-by date hasn't yet again gone flying by with us
having said nothing. (And bear in mind that RFCs and BCPs are
nowhere near as normative as the sell-by date on your local
litre of milk;-)

Cheers,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Oct 2014 06:00:03 +0000

> pattern is inappropriate to use with such dodgy algs.

I'd very much like to agree with you this year.  My concern is that
for now, there are still too many RC4-only sites, and disabling
RC4 will do more harm (in opportunistic TLS) than good in two ways:

    * Some communication will needlessly fall back to cleartext
      after STARTTLS fails, which might have succeeded with RC4.

    * Some communication will not fall back, and force users to
      statically downgrade transmission to cleartext by policy.
      Said policy will rarely get reviewed, and the RC4-only peers
      will be "pinned" at cleartext even after they upgrade.

Thus, while I am 100% for deprecation of RC4, the first step before
banning is I think a less radical phase-out.  With a bit of luck
sensible SMTP administrators will ignore the draft MUST NOT USE
language, and will instead arrange for RC4 to be a last-resort.
A few years from now, RC4 use will truly be negligible, and we can
start removing support.

If excluding opportunistic security is too painful, and it is better
for the draft to have an undiluted message than a nuanced one based
on more pragmatic considerations, fine, so be it, make it pure.
We'll muddle along violating it as necessary.

-- 
	Viktor.

P.S.  More eloborate TL;DR observations:

While I've largely eliminated inbound RC4 for my domain by configuring
the SMTP server to override client cipher suite preference with
more sensible settings on the server, I'm still sending out some
RC4 traffic, because Gmail overrides my client's cipherlist order
and elects ECDHE-RSA-RC4-SHA first.

If Google has not yet got the memo, it is perhaps premature to
expect the rest of the world to be ready.

If the draft goes ahead as-is, I'm of course prepared to offer
people advice on when/how to ignore its requirements, if needed to
resolve operational issues, but would prefer to not have to do
that.

I'd prefer to see a ban on RC4 for opportunistic uses a few years
after it is successfully eliminated for "strict TLS" and largely
phased out in opportunistic use with preference for RC4 over AES
disabled at most sites (more hardware AES support, fewer ancient
systems, ...).

At the end of the day, sure banning RC4 outright would not be
tragic.  People will largely continue to do what they're doing
today, and will generally only implement changes as part of software
upgrade cycles.

This means, for example, that if RC4 disappears from OpenSSL's
"DEFAULT" cipher list on the "master" (future 1.1.0) branch, and
OpenSSL 1.1.0 is released some time in 2015, operating system
releases might make this available to users in 2016, and users will
begin to adopt this in noticeable numbers by 2018.

So RC4 is likely with us through 2020, no matter what the RFC says.

Thus, for what it's worth, I am trying to prevent ~5 years of undue
pressure on thinking administrators from unthinking auditors.  By
2020, opportunistic TLS should I expect be ready to begin running
RC4-free.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Oct 2014 03:08:35 -0400

> If excluding opportunistic security is too painful, and it is better for the draft
> to have an undiluted message than a nuanced one based on more pragmatic
> considerations, fine, so be it, make it pure.

I believe this is the consensus.

---

From: Hubert Kario <[email-masked]>
Date: Thu, 23 Oct 2014 15:31:24 +0200

>       will be "pinned" at cleartext even after they upgrade.

Looking at web servers, less than 1% support only RC4 ciphers, the
rest of the 21% that end up negotiating RC4 will gladly negotiate
different ciphers (mostly AES based ones) if the client doesn't offer
RC4.

> We'll muddle along violating it as necessary.

How long since we got to know that RC4 is really bad? And this draft
is still not an RFC. Let's say that we will change it to say that the RC4 MUST 
be placed last (both client and server side) and release it today. How long 
will it take to release a new RFC that says that it MUST NOT be used?
How long will it take for majority (let's say 75%) of server admins that are 
not compliant with it to actually implement this policy? How many of them will 
unknowingly ignore it?

Just those issues in itself will cause the RC4 depreciation to have a de facto 
transition period. Just look for statistics of the OpenSSL CCS and Hartbleed 
fixes deployments, and those were security vulnerabilities, not best practice 
recommendations.

Second issue is that opportunistic encryption is completely vulnerable to 
active MITM attack, isn't it? This in itself makes it non-RFC compliant, at 
the very least, from the TLS point of view.

-- 
Regards,
Hubert Kario

---

From: Stephen Checkoway <[email-masked]>
Date: Thu, 23 Oct 2014 13:20:29 -0400

> I believe this is the consensus.

+1

-- 
Stephen Checkoway

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Oct 2014 16:49:51 -0400

> I think there is a significant difference between the security (in particular
> confidentiality) one gets with good and dodgy algorithms which is sufficient
> to argue that the OS design pattern is inappropriate to use with such dodgy
> algs.

I'm having trouble parsing things.  You don't mean "both good and dodgy," but rather "good compared with dodgy" or "good contrasted with dodgy"

Sorry, you IE folks are just too good with words for a poor old yank like me :) 

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Oct 2014 02:07:51 +0100

Hiya,

On 23/10/14 21:49, Salz, Rich wrote:
>> I think there is a significant difference between the security (in
>> particular confidentiality) one gets with good and dodgy algorithms
>> which is sufficient to argue that the OS design pattern is
>> inappropriate to use with such dodgy algs.
> 
> I'm having trouble parsing things.  You don't mean "both good and
> dodgy," but rather "good compared with dodgy" or "good contrasted
> with dodgy"

Yep. I badly write:-) Fair comment though, I wasn't clear so
apologies. As you guessed, what I meant was:

  OS is a fine design pattern. Algorithms can be considered-good
  or dodgy. AES is considered-good. RC4 is dodgy. OS requires
  considered-good algorithms (I think). With dodgy algorithms
  (esp. with ciphertext-only attacks expected soon) OS is no
  better than cleartext for confidentiality. So we ought say
  to not use RC4 when following the OS design pattern.

> Sorry, you IE folks are just too good with words for a poor old yank

And meaninglessly but with more apologies this time to the
estates of Beckett and Joyce:

  Pervasive monitors record, having no alternative, nothing new.
  We may be startled as by a violation of our own privacy.
  As if it wasn't broken already.

Hopefully the latter is sufficiently .ie to pass mustard. And
now you've suggested it, I quite like the idea of Joyce
transcribing PM recordings, and sending those to Beckett the
analyst:-)

Cheers,
S.

> 
> -- Principal Security Engineer, Akamai Technologies IM:
> [email-masked] Twitter: RichSalz
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 24 Oct 2014 02:46:29 -0400

>   to not use RC4 when following the OS design pattern.

There's a vocal minority(?) who strongly disagrees with this, particularly the last sentence.

I ask that the TLS WG chairs determine consensus pretty darn quickly.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Oct 2014 11:43:42 +0100

On 24/10/14 07:46, Salz, Rich wrote:
>> OS is a fine design pattern. Algorithms can be considered-good or
>> dodgy. AES is considered-good. RC4 is dodgy. OS requires 
>> considered-good algorithms (I think). With dodgy algorithms (esp.
>> with ciphertext-only attacks expected soon) OS is no better than
>> cleartext for confidentiality. So we ought say to not use RC4 when
>> following the OS design pattern.
> 

Actually I think only Viktor and I have really gotten into
that part of the discussion. I mean about how OS and RC4
interact. Yes, there are others who'd prefer to go slower
deprecating RC4 or whatever, but their issues aren't related
to OS I think. (And just in case, OS here == Opportunistic
Security [1]).

S.

[1] https://tools.ietf.org/html/draft-dukhovni-opportunistic-security

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 24 Oct 2014 13:37:29 +0000

On Fri, Oct 24, 2014 at 02:07:51AM +0100, Stephen Farrell wrote:

>   considered-good algorithms (I think).

When OS is a just-in-case "upgrade" from cleartext to unauthenticated
encrypted communication, there is requirement for "considered good"
algorithms.  The prime-directive is to not disrupt communication,
only then do we try to encrypt if possible.

Thus, for example, if we're doing STARTTLS with SMTP, the handshake
is:

	C: EHLO amnesiac.example
	S: 250-smtp.example
	S: 250 STARTTLS
	C: STARTTLS
	S: 220 make my day
	C: <TLS client HELLO (with some cipher list)>
	S: <TLS server HELLO (with chosen "best" shared cipher) or else fatal TLS alert!>
	...

The client and server commit to TLS without any prior knowledge of
what cipher suites they might share in common.  If the client's
list is too strict, the server will abort with a TLS alert.  Since
we were willing to send in cleartext had the server not indicated
STARTTLS, any cipher suite (even dodgy) is better than a handshake
failure.

Even if years later some TLA recovers the plaintext after a
crypt-analytic breakthrough finally renders the dodgy vulnerable
at reasonable cost.

The alternative is either cleartext transmission or failure.  The
former is immediately available to the TLA.  The latter is not what
the opportunistic client "signed up for".  It was just trying to
deliver the mail with as much security as is available, but no
more.

Therefore, opportunistic TLS needs to be more permissive.  With
opportunistic TLS stricter policies are counterproductive.

Leaving a cipher suite out is only practical once it is no longer
the best shared cipher with any peers.  Thus we can if we wish
disable EXPORT cipher suites since they are now never used, but it
serves no purpose to do so (they are never used) beyond perhaps
preventing accidents in which a grossly misconfigured peer selects
EXPORT despite having better options.  I have never observed such
an accident.

-- 
	Viktor.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 24 Oct 2014 10:01:23 -0400

> EXPORT despite having better options.  I have never observed such

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

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.

This could probably be further improved by remembering which level of
fallback succeeded on previous attempts, and refusing to fallback further.

I don't think that any of this needs to go in the current draft, though.
 We should be explicitly and unambiguously rejecting RC4, and people
doing TLS-that-is-willing-to-fall-back-to-cleartext can just muddle
along violating the RFC, since they're not even claiming to make the TLS
communications property guarantees to their users anyway.

	--dkg

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 24 Oct 2014 14:12:15 +0000

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

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.

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

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

Browser analogies and strategies work poorly or not at all when
misapplied to SMTP.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 24 Oct 2014 10:31:23 -0400

> Leaving a cipher suite out is only practical once it is no longer the best shared
> cipher with any peers.  

I don't agree with this blanket statement.  Sometimes nothing trumps "something is better than nothing."

When the IETF's leading cryptographers say not to use something, then you're better off with plaintext than a false sense of security for your users.

	/r$

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 24 Oct 2014 10:54:07 -0400

Hi Victor--

>   security, we're no longer discussing the language of the draft. ]

yes, agreed.  thanks for making this explicit.

> opportunistic applications will not immediately change to adhere

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.

> 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

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 24 Oct 2014 14:59:50 +0000

On Fri, Oct 24, 2014 at 10:31:23AM -0400, Salz, Rich wrote:

> When the IETF's leading cryptographers say not to use something,
> then you're better off with plaintext than a false sense of security
> for your users.

There is no false sense of security with non-interactive with
unauthenticated opportunistic TLS.  You expect no security, and
none is claimed.  If passive attacks happened to be avoided, that's
gravy, if not, at least cleartext would not have been stronger.

The MTA logs (if they record the use of TLS at all) will record
the ciphersuite used.  The administrator can make appropriate
conclusions:

    Oct 18 11:42:40 amnesiac postfix/smtp[29005]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.68.26]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 20 19:55:07 amnesiac postfix/smtp[21141]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.68.27]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 22 02:55:59 amnesiac postfix/smtp[8024]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.68.26]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 22 23:51:08 amnesiac postfix/smtp[26570]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.68.26]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 23 01:25:18 amnesiac postfix/smtp[18228]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[64.233.171.26]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 23 04:53:38 amnesiac postfix/smtp[20459]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[64.233.171.27]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 23 21:05:20 amnesiac postfix/smtp[29828]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[64.233.171.26]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
    Oct 24 03:23:26 amnesiac postfix/smtp[1541]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[64.233.171.27]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)

After all the fuss about RC4, I've taken a minute to  add a
destination-specific TLS policy for gmail.com:

    tls-policy:
	gmail.com encrypt exclude=RC4

# postmap tls-policy

    main.cf:
	indexed = ${default_database_type}:${config_directory}/
	smtp_tls_policy_maps = ${indexed}tls-policy

Now I have:

    Oct 24 14:51:57 amnesiac postfix/smtp[10528]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.76.26]:25: TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)

No publically known RC4 attacks apply to MTA to MTA delivery without
SASL AUTH, but there we have it, after enabling server cipher order
preempt on my end, and disabling RC4 for Gmail, who can do better,
I am no longer seeing RC4 in my logs (still enabled for all other
destinations, no idea which ones are still running Exchange 2003).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 24 Oct 2014 15:54:07 +0000

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

Correct.  Asymmetry between client and server.

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

> (which i understand is the traditional prioritization for MTA operators,

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

> produce such a patch for Postfix now.

No problem, we would not accept the patch anyway.  Code complexity
leads to bugs.

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

> non-STARTTLS entirely, messages to that mailserver would be delayed but

Did I mention that code complexity leads to bugs?

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 24 Oct 2014 12:50:18 -0400

Hi Victor--

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

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

> No problem, we would not accept the patch anyway.  Code complexity

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.

> Simply allowing RC4 avoids the need for all the complex code you

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 24 Oct 2014 18:23:35 +0000

On Fri, Oct 24, 2014 at 12:50:18PM -0400, Daniel Kahn Gillmor wrote:

> include pinning.  

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

> Postfix's sending MTA at least keeps track of whether

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

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

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

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

> on how to work around specific forms of misconfiguration that happen to

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

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

---

From: Geoffrey Keating <[email-masked]>
Date: 24 Oct 2014 13:07:04 -0700

...
> the best shared cipher with any peers.

Suppose 20% of hosts will use RC4 if it is offered, and 0.1% will
refuse a connection if RC4 is not offered.  Then by not offering RC4,
you are downgrading 0.1% to plaintext (assuming that's what happens)
and upgrading 20% to a secure cipher---in the short term.  I believe
that in itself is likely to be a win overall.

But, some won't go to plaintext, they will instead fail to deliver
mail.  This will cause them to be fixed.  Others will look for a
different relay host, which might support better encryption.  So maybe
it's 0.01%?

And, in the long term, it's more likely that an administrator will
notice the failed SSL attempts than connections which succeed but use
insecure ciphers.

So, I don't think what you're saying is a general rule, and I think it
doesn't apply in this case.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 24 Oct 2014 20:40:37 +0000

> that in itself is likely to be a win overall.

Well, the 20% "upgrade" is invisible and offers no immediate benefit,
while the 0.1% breakage causes people operational headaches, and
with sites they never specifically wanted encryption for.  They'll
then disable encryption for the site and forget they did that, so
the site is stuck at cleartext "forever".

Anyway, I think I've accepted the probability that RC4 will be a
MUST NOT, but that I'll simply have to ignore this for a few years.

-- 
	Viktor.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Fri, 24 Oct 2014 20:44:47 +0000

>MUST NOT, but that I'll simply have to ignore this for a few years.

That’s my read on it too. I expect many to follow this approach.