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

The intent of draft-ietf-tls-prohibiting-rc4 is exactly what the title says: to prohibit the use of RC4-based cipher suites in the TLS protocol. In practice, prohibiting RC4 means that the TLS clients MUST NOT advertise RC4 support, and the TLS servers MUST NOT select an RC4 cipher suite. Both parts are crucially important to achieve the purpose of the I-D.

If the TLS WG cannot reach rough consensus that RC4 cipher suites need to be prohibited, then I think the way forward is for the WG to reject draft-ietf-tls-prohibiting-rc4, and wait for the RC4 attacks to improve even further.

In the meantime, alternative I-Ds can of course be authored to discourage the use of RC4, although the TLS BCP already does so.

Thanks,

Andrei

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Joseph Salowey
Sent: Saturday, October 18, 2014 11:33 AM
To: Chris Newman
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

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

On Wed, Oct 15, 2014 at 4:40 PM, Chris Newman <chris.newman@oracle.com<mailto:chris.newman@oracle.com>> wrote:
I agree with this:

--On October 4, 2014 3:35:47 +0000 Viktor Dukhovni <ietf-dane@dukhovni.org<mailto:ietf-dane@dukhovni.org>>
wrote:
> Well, I for one am not.   Disabling RC4 does more harm than good
> with opportunistic TLS.  A far better approach in that case is to
> de-priorioritize it.  Giving some check-list enforcing clue-less
> auditor the ammunition to harass users into counter-productive
> "security" measures is not my idea of progress.
> ...
> Not all applications face the same risks, and removing RC4 will some
> applications *less* secure at least some of the time.

As an implementer of a product with TLS/SSL support, I will ignore the three
MUST/MUST NOT statements in this draft. As long as the SSL/TLS library I use
supports RC4, I'm going to support RC4. And I'll be reluctant to upgrade to an
SSL/TLS library that doesn't support RC4 for fear of breaking customer
interoperability and forcing opportunistic connections to clear text.

I believe the goal should be to replace RC4 usage in the real world with use of
stronger cipher suites. I do not believe the current draft will advance that
goal. Statements similar to the single-DES advice in RFC 5469 may advance that
goal. Here are other statements that may advance that goal:

* SSL/TLS software MUST prefer stronger cipher suites (presently AES and 3DES)
over RC4.

* SSL/TLS libraries MUST disable RC4 cipher suites by default. An application
MUST make an explicit SSL/TLS library API call to enable RC4 cipher suites if
they are needed for backwards compatibility.

* SSL/TLS software MUST disable RC4 cipher suites when TLS 1.1 or 1.2 are
negotiated and SHOULD disable RC4 cipher suites by default when earlier
versions are negotiated. For an opportunistic security transmission, such as
for SMTP relay (RFC 3207), RC4 MAY be used as a last resort for
interoperability prior to fallback to transmission without SSL/TLS.

* User agents that employ SSL/TLS for security MUST NOT indicate the connection
is secure when RC4 is used. For example, a web browser that displayed a lock
icon when an RC4 cipher suite was used would fail to comply with this
requirement.

                - Chris

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls