Subject: Re: [Uta] [TLS] Remarks on draft-popov-prohibiting-rc4-01

From: Alyssa Rowan <[email-masked]>
Date: Mon, 30 Dec 2013 18:44:01 +0000

(Hi to the UTA list. Crossposting because of the discussion pertaining
 to a TLS BCP.)

On 30/12/2013 15:20, Yoav Nir wrote:

> Here's the thing. You, me, Yaron and Andrei can tell the world to 
> upgrade in an RFC. The world is not required to listen to us.

Alas, so very true. I'm well aware the gulf between what we'd really
like and what we can actually get is hard to bridge.

> - mail.google.com supports SSLv3, RC4_128_MD5, 3DES_EDE_CBC_SHA

No doubt a very considered example. I'm sure agl (et al) could
enlighten us as to why the presence and ordering of each suite;
probably targeting individual demographics.

On 30/12/2013 16:11, Eric Rescorla wrote:

> As a reality check, maybe we could get AGL, bsmith, Andrei, Wan-Teh
> etc. to weigh in on how small the RC4-only population would have to
> be before they are willing to turn off RC4 support in their 
> products.

That would be demographically enlightening. (If a little depressing.)

Allow me to distil my thoughts:

• We want to avoid RC4 whenever possible, because it is insecure
  - How insecure? From what we know, and what we guess:
    · Nation State Adversary: Probable complete failure
    · Public knowledge: Suspected imminent failure
    · Anything's better than plaintext - even RC4
    · But so are export ciphers, and we rightly don't use those anymore!
  - Today's NSA attack may be tomorrow's public attack
    · Tomorrow's attacks applicable in retrospect to today's traffic!
    · Which is why NSA save everything, even if they can't break it now
  - Conclusion: Every time we negotiate RC4, it's a bad outcome
    · We should avoid it whenever it is possible to do so
    · But it may not be possible for some to avoid it

• Is TLS 1.0 AES-128-CBC preferable after all where possible?
  - Agreed, we should definitely ask CFRG for input
  - I personally suspect yes:
    · BEAST & Lucky13: active, noisy, and at least have some mitigation
    · But an RC4 break might be passive, and historically applicable
    · That's suggestive to me that RC4 is more dangerous than AES-CBC

• Some bad clients, and some bad servers, only support RC4
  - There is no secure way left to connect to them
  - They're doomed: we can only do the best we can & encourage upgrade

• Do we want to hard-fail on insecure connections?
  - Depends; no easy answer
  - Our job is to not be insecure; implementations have other priorities
  - If new browser can't connect to a site, user blames the new browser
  - If customers can't connect to new server, new server gets the blame
  - Conclusion: We need a transition period, with RC4 as "last resort"?

• How can we make sure it's a last resort?
  - Downgrade protection { draft-bmoeller-tls-downgrade-scsv-01 }
    · We _really_ need this!
    · Else attacker can trick us back into SSLv3 and/or RC4, or worse?
  - Remove known-insecure ciphersuites from TLS 1.3?
    · Revisit later.

• Should we warn if RC4 is negotiated as a last-resort?
  - Yes, I think we should
    · Clients: similar 'server insecure' warning, like RSA-512 / MD5?
    · Servers: likely want to support legacy clients for a while
    · But might want to loudly warn/encourage them to upgrade _now_

• Practical replacements we can roll out without ruffling feathers:
  - TLS 1.2: ChaCha20_Poly1305 { draft-agl-tls-chacha20poly1305-01 }
    · Faster than RC4
    · 2^256 conf; 2^90 auth, ish
    · Better than AES (side channel avoidance; apparently stronger)
    · Requires TLS 1.2 because AEAD
  - TLS 1.2: AES-128-GCM
    · Already in TLS 1.2 (and NIST Suite B); deployment ongoing
    · Complicated to avoid side-channels in software implementations
    · But fast & good hardware support available on some platforms
    · Requires TLS 1.2 because AEAD
  - TLS 1.1/1.0: ChaCha20_SHA { draft-mavrogiannopoulos-chacha20-tls }
    · Worse authenticator than ChaCha20_Poly1305
    · But backwards-compatible with TLS 1.0 & TLS 1.1
    · And much better than any other choice available there
    · Good third choice; second, if AES-GCM not hardware accelerated
    · Not loving having to use HMAC_SHA1 but TLS 1.0/1 is stuck with it
    · When would this be useful? TLS 1.2-intolerant middleware? (Which?)

• How can we encourage adoption?
  - TLS BCP
    · Being handled by (very new) UTA list
    · Likely delay as a result; not ideal, but forward-thinking
    · Try to get some momentum? (Thus, crossposted for discussion.)
  - Once finished: point standard/compliance orgs to TLS BCP?
    · PCI DSS might provide some incentive, even to geological-time
      inertia of financial orgs? Maybe?
    · Anyone else?
  - Any other ideas?

- -- 
/akr

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 31 Dec 2013 12:26:31 +0200

Hi Alyssa,

Thanks for the thorough analysis.

A quick background/motivation regarding the BCP - which of course is 
open to discussion.

The idea was to recommend only things that are currently standardized, 
and already widely (though definitely not universally) implemented. This 
strategy narrows the field down considerably, maybe too much, and 
precludes things like Nikos's ChaCha draft. But it means that with a bit 
of industry push, the RFC will be usable by *implementors* within 6-12 
months.

Thanks,
	Yaron

On 12/30/2013 08:44 PM, Alyssa Rowan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
[snip]

---

From: Watson Ladd <[email-masked]>
Date: Mon, 30 Dec 2013 17:27:11 -0500

On Mon, Dec 30, 2013 at 2:59 PM, Manuel Pégourié-Gonnard
<[email-masked]> wrote:
> On 30/12/2013 19:44, Alyssa Rowan wrote:
<snip>
> I think there are two kinds of servers here:
>
> 1. The servers which can negotiate something better than RC4, but will also
> negotiate RC4 if the client doesn't offer anything better. It solves the "likely
> want to support legacy clients for a while" issue for server admin, without
> hurting security too much (actually not at all if/when we have downgrade
> protection).
>
> 2. The servers which can negotiate something better but actually prefer RC4. For
> example, right now google.fr seems to prefer RC4 over any other cipher Firefox
> 26 or Chromium 30 offer, which include AES-CBC (but not AES-GCM).
> If we agree that RC4 is more dangerous than AES-CBC, then these servers are
> actively hurting security.

I think it is important to distinguish between configuration changes
(hopefully easy)
and upgrades (not so easy). If it was possible to distinguish between
1/n-1 record
splitters and not, we would be able to use RC4 only when necessary.
But it isn't possible,
so either you upgrade to something reasonable like AES-GCM, or you are
faced with
picking your poison.

Putting RC4 first hurts modern browsers that want it on for backwards
compat. Putting
TLS_3DES_EDE_SHA1 (I might not have that right) first doesn't, and
makes the best
attack active over passive. But the average sysadmin doesn't make the
right call: our
RFC would tell them to change the configuration to disable RC4.

>
> Since I know there are a lot of knowledgeable people who care about security at
> google, I might be missing something here.

They've been pushing Chrome for years: when I connect to gmail, it's
with AES-GCM over TLS 1.2
and ECDH_ECDSA.
>
> Manuel.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin