Subject: [secdir] secdir review of draft-ietf-tls-prohibiting-rc4-01

From: Tom Yu <[email-masked]>
Date: Tue, 09 Dec 2014 19:21:13 -0500

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Summary: ready with minor issues

This document deprecates RC4 cipher suites in TLS due to attacks that
can recover repeated plaintexts given about 2^26 sessions.  Accordingly,
it says that TLS implementations MUST NOT use RC4 cipher suites.

However, I noticed that RFC 5469 specifies only "SHOULD NOT" for
single-DES cipher suites in TLS.  I don't know whether a 2^56 offline
exhaustive key search that reveals an initial plaintext is directly
comparable to a 2^26 online attack that reveals the entire plaintext,
but it seems odd that single-DES is only "SHOULD NOT" while RC4 is "MUST
NOT".  Perhaps this document is not the right place to fix that
discrepancy.

On the other hand, I am wondering if an unintended consequence of sites
or implementations disabling RC4 cipher suites is falling back to
single-DES.  What prevents this fallback from happening?  I don't have a
lot of the relevant information about TLS implementations as deployed.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 10 Dec 2014 00:49:55 +0000

Hi Tom,

> NOT".  Perhaps this document is not the right place to fix that

That point was debated at length by the WG, which eventually
did reach a relatively strong consensus on the MUST NOT
despite the knowledge that some people might need to keep
RC4 around even after this is published.

> lot of the relevant information about TLS implementations as deployed.

No, single-DES doesn't feature. Triple-DES is implemented but
slow. AES as a h/w instruction on various chips (incl. many
intel processors and others) is relatively widely available
and is faster and better than RC4. For those without AES h/w
the likely evolution will be to chacha20 which is also being
worked between the TLS WG and CFRG and which is actually
already deployed in some browsers. (And which has good lineage
via the eStream crypto competition. Well, good enough according
to CFRG, which is why they're involved.)

Cheers,
S.

> 
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 10 Dec 2014 00:52:25 +0000

Thanks for the review Tom,

There are definitely other weak cipher suites defined for TLS: EXPORT, NULL, MD5, DES to name a few. It was not easy to reach consensus on deprecating just one algorithm (RC4). Bundling other weak crypto into the same I-D would probably have caused even more opposition, so my preference would be to tackle those in separate I-D(s).

> On the other hand, I am wondering if an unintended consequence of sites or implementations disabling RC4 cipher suites is falling back to single-DES.  What prevents this fallback from happening?
Unlike RC4 (which is widely supported and preferred by multiple TLS clients and servers), single-DES is already disabled by default in those TLS clients and servers that receive regular updates. Publishing an IETF document prohibiting single-DES is probably still worthwhile, just less impactful in terms of providing guidance to the industry.

Cheers,

Andrei

-----Original Message-----
From: Tom Yu [mailto:[email-masked]] 
Sent: Tuesday, December 9, 2014 4:21 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: secdir review of draft-ietf-tls-prohibiting-rc4-01

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document deprecates RC4 cipher suites in TLS due to attacks that can recover repeated plaintexts given about 2^26 sessions.  Accordingly, it says that TLS implementations MUST NOT use RC4 cipher suites.

However, I noticed that RFC 5469 specifies only "SHOULD NOT" for single-DES cipher suites in TLS.  I don't know whether a 2^56 offline exhaustive key search that reveals an initial plaintext is directly comparable to a 2^26 online attack that reveals the entire plaintext, but it seems odd that single-DES is only "SHOULD NOT" while RC4 is "MUST NOT".  Perhaps this document is not the right place to fix that discrepancy.

On the other hand, I am wondering if an unintended consequence of sites or implementations disabling RC4 cipher suites is falling back to single-DES.  What prevents this fallback from happening?  I don't have a lot of the relevant information about TLS implementations as deployed.