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

From: Watson Ladd <[email-masked]>
Date: Sun, 29 Dec 2013 22:32:51 -0500

Dear all,

A short draft telling us what we all should be doing anyway? No
extensions required, just banishing the RC4 ciphersuites to the place
they belong.
All TLS implementations include other ciphers, so there isn't much of
an interop issue here AFAIK. Several implementations have already made
this change, so I think we should officially bless it. Even if later
BCP's reiterate the advice, there isn't harm in restating it.

If people have other opinions I would be interested in hearing them.

Sincerely,
Watson Ladd

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 Dec 2013 09:50:32 +0000

My only issue with this, is that clients and servers have to deal with the installed base, and the installed base includes IE6 running on XP, several older versions of Safari on outdated OSX, Firefox 3.6, and thousands of web servers running anything you can think of.

So if you take away RC4, you still have to support CBC ciphersuites for 3DES (maybe AES would work most of the time…) without the modification being discussed in another thread.

So given the choice between RC4 and 3DES-CBC without P-E-M and without fancy 1-byte-record BEAST mitigation, which would you prefer?

Yoav

---

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

On 30/12/2013 09:50, Yoav Nir wrote:
> My only issue with this, is that clients and servers have to deal 
> with the installed base, and the installed base includes IE6 
> running on XP, several older versions of Safari on outdated OSX, 
> Firefox 3.6, and thousands of web servers running anything you can
>  think of.

Then the installed base *requires* an update: it can no longer connect
securely, and transport layer _security's_ job is to not be insecure.
Inertia can only go so far, but at some point, we _have_ to rip the
plaster off. We don't support export-mode anymore, do we?

I'd push for removing RC4 support _completely_ - and 3DES-CBC to have
a security warning and not supported unless you really want to support
legacy clients. I'd begrudgingly support good old AES-128-CBC w/ SHA
in TLS v1.0 for legacy (and no MD5 or MD2 at all, either).

I'd want EV (green-bar) server requirements to require full compliance
with draft-sheffer-tls-bcp (or whatever it becomes). I'd suggest
TLSv1.2 AES-GCM as a minimum, and probably also (going forward)
ChaCha20_Poly1305 support - and downgrade protection, when we can get
it out there. Also SHA-256 rather than SHA-1.

RC4 is broken. It is unsuitable for any purpose - and that's what we
know as civilians. You should no more use RC4 in 2014 than you should
be using the 40-bit "export-mode" ciphers: please turn it off!

NSA/GCHQ found it extremely convenient (maybe _too_ convenient) that
people were using RC4 to mitigate BEAST.

They also warned that the 'cryptologic breakthrough', though
convenient, was temporary and fragile (i.e. people would soon be
advised to stop using it - which is of course what we are discussing
here!).

Tentative conclusion: Whatever break the NSA/GCHQ have for RC4 is
worse than BEAST - possibly even plaintext-recovery in real-time or
near-real-time?! Whatever it is, they were _joking_ about its
security, or lack thereof.

I think RC4, and the CA model as it currently stands, are TLS's
biggest security issues re: perpass, and in general. RC4 is definitely
the easier one to fix: we turn it off.

Let's remember the broader picture too: XP goes EOL in April, and this
could well result in a flurry of 0days (deliberately held back until
after EOL) that will probably not be patched. Possible result: open
season on internet worms, maybe something along the scale of NIMDA or
Sapphire. Continuing to support an insecure IE6 even in the face of
that seems optimistic.

Of course, that's only my insignificant viewpoint; and what I'd like
may be infeasible in the short-term. I'm aware that inertia can be a
tricky point: probably one of the biggest challenges for TLS.

- -- 
/akr

---

From: Watson Ladd <[email-masked]>
Date: Mon, 30 Dec 2013 07:48:31 -0500

> So given the choice between RC4 and 3DES-CBC without P-E-M and without fancy 1-byte-record BEAST mitigation, which would you prefer?

3DES-CBC. BEAST requires the ability to inject data on record
boundaries, and 3DES attacks are chosen-plaintext. Given that IE6
doesn't
support the new features that permit such an injection, it's not my
favorite thing in the world, but better than RC4.

RC4 has lots more problems: we don't know what they are because until
recently everyone in academia thought no one was using it.
Jacob Appelbaum is saying it can "read" but he's not provided the
documentation to back that one up. It is however worrying that
every time someone graphs something from RC4, we get a pretty graph.

Sincerely,
Watson Ladd

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Dec 2013 05:59:47 -0800

> favorite thing in the world, but better than RC4.

Not to disagree with the main point that we should be more interested
in removing RC4, but what Web browser features do you believe are
required to mount attacks on CBC cipher suites?

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Mon, 30 Dec 2013 10:20:38 -0500

> required to mount attacks on CBC cipher suites?

You need to be able to inject chosen-plaintext with a high degree of
control into an existing TLS connection.
The BEAST demo used Java, but Websockets was also vulnerable. The AJAX
stuff hasn't be used to the
best of my knowledge to mount this attack: there is enough junk before
what the attack controls to make
life difficult. There is a reason it was ~9 years between the papers
explaining the issue and a demo.

Lucky 13 and friends can be mounted anyway, but if the connection is
torn down on padding error it takes a while
to have any luck.

The problem however is we have remediations for BEAST and Lucky 13 in
modern browsers, but not RC4.
RC4 does not get negotiated only for IE6 on XP: 36.2% of sites
SSLPulse surveyed use it with modern browsers.
Worst case, we might be feeding IE6 on XP to the wolves in order to
protect everyone else.

I understand this is going to be EOL in a few months, so I don't feel
bound to be nicer to it than its maker.

Sincerely,
Watson Ladd

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 Dec 2013 15:20:54 +0000

On Dec 30, 2013, at 2:01 PM, Alyssa Rowan <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 

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. Browser makers are very wary of creating browsers that don't connect to what's out there. That's why they're willing to downgrade to SSLv3. Server vendors are also wary of locking out a bunch of browsers. Two examples of websites for companies that do care about security:
 - Paypal supports SSLv3, RC4_128_MD5, and 3DES_EDE_CBC_SHA
 - mail.google.com supports SSLv3, RC4_128_MD5, 3DES_EDE_CBC_SHA
 - jpmorgan.com (largest bank in the US) supports SSLv3, RC4_128_SHA, 3DES_EDE_CBC_SHA
 - www.nsa.gov (OK, this is a publicity site, but still) supports SSLv3 and EXPORT_WITH_RC4_40_MD5.  OK, maybe not the best example.

And these are the most security-concious of all. What can the rest of us be expected to do?

> plaster off. We don't support export-mode anymore, do we?

Mostly not.

> in TLS v1.0 for legacy (and no MD5 or MD2 at all, either).

OK. Although that would make a fine "which is worse" question for CFRG.

> with draft-sheffer-tls-bcp (or whatever it becomes).

Again, that would give Paypal (as an example) the choice of giving up a bunch of customers or giving up the green bar.

> I'd suggest

With current browsers, this means Chrome. Yes, IE had GCM first, but only in a Suite-B ciphersuite. RSA with ECDHE and GCM is Chrome only, and only a recent version of Chrome. That implies cutting off some pretty recent browsers and devices.

> Sapphire. Continuing to support an insecure IE6 even in the face of

We don't know that this is going to happen. The high-value computers have migrated, and the 30% that still use XP are likely low-value. We may not see attacks at all. XP will not stop working just because Microsoft has decided to stop support. Many users weren't updating their OS anyway.

> tricky point: probably one of the biggest challenges for TLS.

And that's the point of writing the BCP and this draft.

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Dec 2013 07:50:27 -0800

> control into an existing TLS connection.

Not only an existing TLS connection but one that contains data
that the attacker would otherwise not be able to access, like
a cookie.

> The BEAST demo used Java, but Websockets was also vulnerable.

To the best of my knowledge, while a draft version of WebSockets
(WebSockets-76 IIRC) was vulnerable WebSockets as standardized
in RFC 6455 was not vulnerable due to the masking feature
(http://tools.ietf.org/html/rfc6455#section-5.3), though this
feature was introduced for other reasons (see [0]).

-Ekr

[0] http://w2spconf.com/2011/papers/websocket.pdf

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Dec 2013 08:11:49 -0800

On Mon, Dec 30, 2013 at 7:20 AM, Yoav Nir <[email-masked]> 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. Browser
> makers are very wary of creating browsers that don't connect to
> what's out there. That's why they're willing to downgrade to
> SSLv3. Server vendors are also wary of locking out a bunch of
> browsers.

To elaborate on this point a bit, the critical factor here is clients
and servers which support *only* RC4, since that's what causes bustage.
Historically, client vendors have resisted any change which breaks
more than a small fraction of connections (and presumably server
operators feel the same way).

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.

-Ekr

P.S. Ignoring general equilibrium effects simply having clients and servers
configured so that any pair which have a common cipher X better than
RC4 select X instead is still pretty good (assuming that the negotiation
is secured, and we have anti-rollback if necessary), since the impact
would be that X is selected where possible and RC4 where necessary.
Unless I misunderstand, RC4 is still superior to plaintext against the
current best results.

---

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:

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

> 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: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 30 Dec 2013 20:59:13 +0100

>     · That's suggestive to me that RC4 is more dangerous than AES-CBC
I tend to agree: being vulnerable to passive attacks is much worse than being
vulnerable to active attacks. Besides the fact than passive attacks can be done
more pervasively, they also can be done in the future on material recorded now
(as you note earlier).

> [...]

I really like the idea of using RC4 as a last-resort but with a loud warning. It
shifts the blame from the new browser to the "old" server.

I'm curious to hear opinions of browser people on this idea.

>     · But might want to loudly warn/encourage them to upgrade _now_
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.

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

Manuel.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 30 Dec 2013 21:21:28 +0100

[forking thread for discussion on a side point]

>     · Not loving having to use HMAC_SHA1 but TLS 1.0/1 is stuck with it
Are we really stuck with SHA1 (as opposed to SHA-256 or SHA-384) for HMAC on TLS
1.0 and 1.1?

At least three RFCs (5487, 5489 and 6367) that define ciphersuites with
HMAC-SHA2 explicitly allow them to be used with TLS < 1.2. Quoting from RFC 6367
(section 3.3) for example:

   The hash algorithms and pseudorandom function (PRF) algorithms for
   TLS 1.2 [8] SHALL be as follows:

   a.  The cipher suites ending with _SHA256 use HMAC-SHA-256 [1] as the
       MAC algorithm.  The PRF is the TLS PRF [8] with SHA-256 [13] as
       the hash function.

   b.  The cipher suites ending with _SHA384 use HMAC-SHA-384 [1] as the
       MAC algorithm.  The PRF is the TLS PRF [8] with SHA-384 [13] as
       the hash function.

   When used with TLS versions prior to 1.2 (TLS 1.0 [2] and TLS 1.1
   [6]), the PRF is calculated as specified in the appropriate version
   of the TLS specification.

On the other hand, at least one other RFC that defines SHA-2 and ciphersuites
explicitly prohibits their use with TLS < 1.2. Quoting from RFC 5932 3.3.3:

   The cipher suites ending with _SHA256 use HMAC-SHA-256 as the MAC
   algorithm.  The PRF is the TLS PRF [RFC5246] with SHA-256 as the hash
   function.  These cipher suites MUST NOT be negotiated by TLS 1.1 or
   earlier versions.  Clients MUST NOT offer these cipher suites if they
   do not offer TLS 1.2 or later.  Servers that select an earlier
   version of TLS MUST NOT select one of these cipher suites.

At least one other RFC (5289) defines SHA-2 suites without any hint about
whether they can be used with TLS < 1.2 or not. (We count even count RFC 5246 in
this category.)

It seems to me that allowing HMAC-SHA256/384 with TLS 1.0 and 1.1 should not be
a problem for implementers. At least, I didn't see a problem when lowering the
version requirements for the ciphersuites from RFCs that allow them with < 1.2
in PolarSSL, but on the other hand I couldn't test interop since I was unable to
find another implementation that uses those SHA-2 suites with TLS < 1.2...

What is the group's opinion on using HMAC-SHA256/384 suites with TLS < 1.2?

Manuel.

---

From: Alyssa Rowan <[email-masked]>
Date: Mon, 30 Dec 2013 21:52:19 +0000

> What is the group's opinion on using HMAC-SHA256/384 suites with

Why stop there? We had the SHA-3 competition last year: if we intend
to replace SHA-1, why use SHA-2?

The competition yielded five excellent replacements, some of which are
faster than SHA-2¹, none of which were designed by the NSA², and none
of which have length-extension attacks³: Keccak (selected by NIST as
SHA-3), Skein, BLAKE, JH and Grøstl.

Perhaps we should make our own determination and/or take advice from
CFRG as to which of these might be suitable for future use in the
alternative?

To me, the leading three from the SHA-3 finalists are:

• Keccak (SHA-3):
  - Poorish software performance: roughly SHA-2 speed or slower.
  - Not as well analysed as some other SHA-3 candidates.
  - NIST-approved. (Is this a positive or negative now? <g>)
  - Possible _future_ good hardware performance, due to being selected
    as SHA-3: not likely to be relevant for years yet, however.
  - NIST didn't eventually make any midnight-hour changes: trust issues.
• Skein:
  - 72 round fast ARX tweakable block cipher core with a smooth finish.
  - Excellent software performance - roughly 2× SHA-2 & SHA-3 speed.
  - Very well-analysed.
• BLAKE:
  - Based on a tweaked ChaCha14/ChaCha16, lengthways and diagonally.
  - Excellent software performance, competitive w/ Skein (just loses)
  - Very well-analysed.

JH or Grøstl are slower so not as attractive.

While Skein was my favoured of the bunch in general, I note the
delicious symmetry of BLAKE being based upon a slightly modified
version of the stream cipher we're planning to use.

I'd therefore tentatively suggest ChaCha20_HMAC-BLAKE256 as a TLS 1.0/
1.1 alternative to ChaCha20_Poly1305, if it's thought appropriate
(CFRG?), and I'd suggest that over and above HMAC-SHA256.

And software performance right now I feel is more relevant for the
ChaCha20 ciphersuites, because those are especially good for platforms
where AES & GCM hardware acceleration isn't available, and it's hard
to suppose of a future platform that would accelerate SHA-3 but not
AES or GCM.

Whereas for TLS 1.3, perhaps I could see SHA-3 as a NIST-selected
alternative alongside Skein or BLAKE, for possible future agility.

Thoughts?

___
1. Current performance: <http://bench.cr.yp.to/graph-sha3/long.png>
2. I don't think the NSA intentionally weakened SHA-2. It's OK,
   length-extension aside. But we can have more independent confidence
   in something they didn't design.
3. Which resulted in NIST calling the SHA-3 competition.

- -- 
/akr

---

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

>>   - Agreed, we should definitely ask CFRG for input
<snip>
> 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.

> 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

---

From: Watson Ladd <[email-masked]>
Date: Mon, 30 Dec 2013 18:18:23 -0500

> alternative alongside Skein or BLAKE, for possible future agility.

Even if SHA-1 is utterly broken, this won't necessarily break HMAC based on it.

I also don't like the idea of backporting: if we are going to be
patching systems and forcing
upgrades, why not to TLS 1.2 which doesn't have these issues?

Chacha20+Poly1305 is a good addition to TLS 1.2 for devices without
hardware support.

When it comes to hash functions, negotiating the use of the hash
function in the handshake doesn't
solve anything: if the hash function to which you feed the handshake
is broken enough to allow for interfering
with the handshake, then the attacker can dictate it. It takes a very
broken hash function to make key negotiation
with it a bad idea, and HMAC has similar robustness. I don't think
SHA256 is going to fall that way. (In particular,
the data the attacker can influence goes after the ciphersuites used

The one place we really depend on hash functions is in the signatures
that tie the key negotiation to the certificate
chain. There are ways around it like MQV, but that is patented. SHA256
has been more resistant than expected here,
but we certainly could put some flexibility in in TLS 1.3 without
hurting latency.

Sincerely,
Watson Ladd
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJSwesSAAoJEOyEjtkWi2t6uugP/2wQLTWKCfoubEmYl1D/wVEv
> BKo38oNJHQoKmJOgqUmoRYp4BDzeVcNDsllnESIJi5uc3O/tkIoTCgbbpiAO0tW3
> MH2c+Hg3Qf+BjjbovMDf45ekFkz3+3onR1TI2Vh6tMP2fybbAiBZXZ2fWpdk0d5H
> wArhOV4nBXWDPnjCNJpvstOwaXmR3cgkE7tNwMUXXJ7Dr4mm93kYpaM+ztAQ/DZj
> VHA5AfX4JRXajK3S5qkmJdZokMWDU7VPkt58AcyCudRCZY/ROFuqRe2H3E8ryG5J
> VXYqGLYxUrsagFCahYBwYbpGXtiHs6Jveb+MAdsB7ZOmGpPlkKijzGQs7CGOcnFb
> 35fH+steCMskZbaS5pq0+47TdFkIIvWCobiPso8s4ohP1k1zF78dki9/cWMQ8U4W
> DpxWKrE0WDYDogpLXtmomoF3W5CFYNXBIMHBrcyP1nLthqSGDwL8FHGvOlQ/1gOW
> p51CeNrOOVGK11dX90A/u5zRwXgn8PjoiT+tJ/DjznCuTcLphKeNU1SdNg5jxYeZ
> 98Wqp5QBs9U+Cdfqoncp2fYOiLt0RcVCbb1uO5ps2dyPkTNSSswhF5SSM82OK4N3
> /ZqF1v7ZWp2YJ/3tRH87pXXztenTAovITQsbT6Fxswx2dKmHMUHmOSXCfFyCl+As
> GT3gIhkHm2wMsanNAoZE
> =w3Z3
> -----END PGP SIGNATURE-----

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Tue, 31 Dec 2013 01:46:42 +0100

> upgrades, why not to TLS 1.2 which doesn't have these issues?
Well, that was more or less my question: is using SHA-2 for HMAC with
TLS < 1.2 really backporting? I just checked RFC 2246 and 4346 and they
both state:

    Additional hash algorithms can be defined by cipher suites and
    used to protect record data, but MD5 and SHA-1 are hard coded into
    the description of the handshaking for this version of the protocol.

So, I'm really under the impression that there is nothing that prevents
anyone from defining a SHA-2 ciphersuite and using it with TLS < 1.2,
with the understanding that the PRF (hence the handshake authentication)
remains based on MD5 + SHA1.

However, a number of facts (akr's recent message, the restriction in RFC
5932, the fact that neither OpenSSL nor GnuTLS accepts to negotiate any
SHA-2 suite with TLS < 1.2) seems to indicate otherwise, so I wanted to
check if I missed some good reason not to use SHA-2 suites with TLS <
1.2.

Manuel.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Dec 2013 16:47:32 -0800

> Are we really stuck with SHA1 (as opposed to SHA-256 or SHA-384) for HMAC on TLS

It's probably useful to start by discussing the threat model. TLS uses
digests for four
primary purposes:

- To verify signatures on certificates.
- To verify other signatures (arguably this is the same as
certificates, but I am breaking
  it out here for ease of explanation.)
- In the MAC (HMAC)
- As part of the KDF

By far the easiest of these to replace is the MAC, since it's part of
the cipher suite.
There's nothing stopping us defining a new cipher suite (even for TLS 1.0) that
uses some other MAC with another hash [0]. Changing the other usages has
a variety of challenges, which is where the machinery from TLS 1.2 comes in.

With that said, my impression is that the use of SHA-1 in HMAC is comparatively
strong to use for digital signatures (and of course, the impact is far less than
if someone can forge a certificate signature). And for the usual
deployment reasons
we are likely stuck with SHA-1-based certificates and clients that accept them
for quite some time. Note that even if you support TLS 1.2, you
probably still have
to accept SHA-1 for interop reasons. [1]

With that in mind, how much extra security benefit do we get from replacing
HMAC-SHA1 with HMAC-<something>, as long as we still have SHA-1 for certificates
and signatures? And if we're considering only replacing the MAC, it seems like
it might make sense to go with a MAC that is not hash based at all.

-Ekr

[0] This is specified, at least in 2246, as HMAC
(http://tools.ietf.org/html/rfc2246#section-6.2.3.1)
but technically it wouldn't be hard to write a new ciphersuite overriding this.

[1] For instance, my current connection with Chrome to Google uses
AES-GCM but the
cert is RSA-SHA1.

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 31 Dec 2013 02:27:51 +0000

Eric,

I would think that it would be appropriate to break out use of SHA-1 for verifying signature on the certificate from other usages of SHA-1 to verify signatures on ephemeral keys and client authentication, etc.

We know that use of weak hash can be exploited by an attacker depending on how certificates are issued.

But, for signatures by the client and the server on the keys or authentication, I do not think there is a collision motivation and hence SHA-1 would be ok there.

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Monday, December 30, 2013 7:48 PM
To: Manuel Pégourié-Gonnard
Cc: [email-masked]
Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01

On Mon, Dec 30, 2013 at 12:21 PM, Manuel Pégourié-Gonnard <[email-masked]> wrote:
>>   - TLS 1.1/1.0: ChaCha20_SHA { draft-mavrogiannopoulos-chacha20-tls 
>> } [...]

It's probably useful to start by discussing the threat model. TLS uses digests for four primary purposes:

- To verify signatures on certificates.
- To verify other signatures (arguably this is the same as certificates, but I am breaking
  it out here for ease of explanation.)
- In the MAC (HMAC)
- As part of the KDF

By far the easiest of these to replace is the MAC, since it's part of the cipher suite.
There's nothing stopping us defining a new cipher suite (even for TLS 1.0) that uses some other MAC with another hash [0]. Changing the other usages has a variety of challenges, which is where the machinery from TLS 1.2 comes in.

With that said, my impression is that the use of SHA-1 in HMAC is comparatively strong to use for digital signatures (and of course, the impact is far less than if someone can forge a certificate signature). And for the usual deployment reasons we are likely stuck with SHA-1-based certificates and clients that accept them for quite some time. Note that even if you support TLS 1.2, you probably still have to accept SHA-1 for interop reasons. [1]

With that in mind, how much extra security benefit do we get from replacing
HMAC-SHA1 with HMAC-<something>, as long as we still have SHA-1 for certificates and signatures? And if we're considering only replacing the MAC, it seems like it might make sense to go with a MAC that is not hash based at all.

-Ekr

[1] For instance, my current connection with Chrome to Google uses AES-GCM but the cert is RSA-SHA1.

> HMAC-SHA2 explicitly allow them to be used with TLS < 1.2. Quoting 
> from RFC 6367 (section 3.3) for example:
>
> On the other hand, at least one other RFC that defines SHA-2 and 
> ciphersuites explicitly prohibits their use with TLS < 1.2. Quoting from RFC 5932 3.3.3:
>
> At least one other RFC (5289) defines SHA-2 suites without any hint 
> about whether they can be used with TLS < 1.2 or not. (We count even 
> count RFC 5246 in this category.)
>
> It seems to me that allowing HMAC-SHA256/384 with TLS 1.0 and 1.1 
> should not be a problem for implementers. At least, I didn't see a 
> problem when lowering the version requirements for the ciphersuites 
> from RFCs that allow them with < 1.2 in PolarSSL, but on the other 
> hand I couldn't test interop since I was unable to find another implementation that uses those SHA-2 suites with TLS < 1.2...
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 30 Dec 2013 22:38:58 -0500

>    it out here for ease of explanation.)
There's also:
To verify the finish message (but this could easily be a CMAC or GMAC).
To produce public pseudo-random data (this is done currently as part of 
the key expansion step, but arguably shouldn't be).

Let me split this up a bit differently:

TLS1.2 (hardwired protocol) uses a PRF function for the KDF, for the MAC 
over the finish message and for producing pseudo-random data. The 
generic PRF is based on HMAC-SHA256, but there's no reason that the PRF 
needs to be based on a hash.

Suites MAY use a hash as part of a certificate signature verification 
(but not necessarily - i.e. PSK suites), and for MAC (again, not 
necessarily - i.e. CMAC or CCM suites).

Out of all of these, the one where hashes are most deeply embedded and 
where this WG has the least ability to affect change is certificates.  
(I agree with your comment below that we're not likely to be able to 
change this in the near future).

> it might make sense to go with a MAC that is not hash based at all.

I think you have to talk about this as replacing the base function for 
the PRF (unless you want to respec TLS1.2?).

Assuming there's no security issue with replacing the HMAC in the PRF 
with a CMAC, you could define a PSK suite that could be implemented with 
nothing more than the AES encrypt operation. (e.g. 
TLS_PSK_WITH_AES_128_CCM_CMAC)

I think you'd have to define some adaptations though  - an HMAC can take 
a key of any length, while a CMAC requires a key of length of the 
underlying block cipher.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Dec 2013 20:00:54 -0800

On Mon, Dec 30, 2013 at 7:38 PM, Michael StJohns <[email-masked]> wrote:
> I think you have to talk about this as replacing the base function for the
> PRF (unless you want to respec TLS1.2?).

Sorry, I was just talking about the message MAC, which you should
be able to change in all versions of TLS. And as I said above, I'm not
sure how useful that is in isolation.

-Ekr

---

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

> like and what we can actually get is hard to bridge.
[snip]

---

From: Andrei Popov <[email-masked]>
Date: Tue, 31 Dec 2013 17:08:47 +0000

Hi Eric,

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

It would be hard to give a specific number or percentage of RC4-only servers that a browser vendor can ignore, because no browser vendor wants to be less compatible than the others. Also, while such a number or percentage could practically be estimated by scanning the public Web, it would be difficult to get reliable data about all the private intranets out there.

Also, I believe the bulk of RC4 connections are negotiated because servers are configured to prefer RC4, not due to RC4 being the only common cipher suite between the client and the server. IE 11 already somewhat alleviates this problem by not offering RC4 on the initial connection attempt.

It is true that browser vendors, server operators, etc. are not required to listen to the TLS WG. However, I also believe that deprecating weak cipher suites (and adding new, secure ones) is due diligence for this WG, and that it sends a strong message to the vendors/operators.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Monday, December 30, 2013 8:12 AM
To: Yoav Nir
Cc: <[email-masked]>
Subject: Re: [TLS] Remarks on draft-popov-prohibiting-rc4-01

On Mon, Dec 30, 2013 at 7:20 AM, Yoav Nir <[email-masked]> wrote:
>>> with the installed base, and the installed base includes IE6 running 
>>> on XP, several older versions of Safari on outdated OSX, Firefox 
>>> 3.6, and thousands of web servers running anything you can think of.
>>
>> Then the installed base *requires* an update: it can no longer 
>> connect securely, and transport layer _security's_ job is to not be insecure.
>
> makers are very wary of creating browsers that don't connect to what's 
> out there. That's why they're willing to downgrade to SSLv3. Server 
> vendors are also wary of locking out a bunch of browsers.

To elaborate on this point a bit, the critical factor here is clients and servers which support *only* RC4, since that's what causes bustage.
Historically, client vendors have resisted any change which breaks more than a small fraction of connections (and presumably server operators feel the same way).

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.

-Ekr

P.S. Ignoring general equilibrium effects simply having clients and servers configured so that any pair which have a common cipher X better than
RC4 select X instead is still pretty good (assuming that the negotiation is secured, and we have anti-rollback if necessary), since the impact would be that X is selected where possible and RC4 where necessary.
Unless I misunderstand, RC4 is still superior to plaintext against the current best results.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls