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

[Joseph Salowey <[e-mail]>]

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 <[e-mail]>
wrote:

> I agree with this:
>
> --On October 4, 2014 3:35:47 +0000 Viktor Dukhovni <[e-mail]
> >
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>