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

[Andrei Popov <[e-mail]>]

Chris's language reads weaker than the TLS BCP, but if folks want to pursue this, that's up to the WG. My point is that this should be a different I-D, because it does not amount to "prohibiting RC4".

Cheers,

Andrei
________________________________________
From: Watson Ladd <[e-mail]>
Sent: Monday, October 20, 2014 5:59 PM
To: Andrei Popov
Cc: Joseph Salowey; Chris Newman; [e-mail]
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

On Mon, Oct 20, 2014 at 5:52 PM, Andrei Popov
<[e-mail]> wrote:
> 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.

We've reached consensus RC4 is not a good idea. But, like Saint
Augustine, "grant me strong ciphers, but not today!".
That said, Chris's approach helps get us some of the way there.

Sincerely,
Watson Ladd
>
>
>
> 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:[e-mail]] On Behalf Of Joseph Salowey
> Sent: Saturday, October 18, 2014 11:33 AM
> To: Chris Newman
> Cc: [e-mail]
> 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 <[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
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> 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