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

[Stephen Farrell <[e-mail]>]

Viktor,

On 22/10/14 18:52, Viktor Dukhovni wrote:
> On Wed, Oct 22, 2014 at 10:28:54AM -0700, Ryan Carboni wrote:
> 
>> This is why SHA-256 will never have a malicious collision, and why RC4 will
>> never be broken.
> 
> Well, never is a long time, and it is already somewhat broken, in that
> the bias in at least firt 256 bytes of output makes fixed plaintexts
> transmitted repeatedly under varying keys vulnerable to recovery.
> 
> While I would prefer to see RC4 phased out more gradually, I do
> not think we can claim that it has not been broken.
> 
> So I think that it would be nice if there was some wiggle-room for
> opportunistic TLS.  As weak as RC4 might be, it is stronger than
> cleartext.  And the published bias attacks don't apply to MTA to
> MTA SMTP.  There is no (pairwise) fixed sensitive plaintext at a
> fixed offset in every MTA to MTA email transaction.
> 
> I have no objections to banning RC4 for "strict" TLS use-cases.

I think there is a significant difference between the security
(in particular confidentiality) one gets with good and dodgy
algorithms which is sufficient to argue that the OS design
pattern is inappropriate to use with such dodgy algs.

The problem is if the ciphertext is recorded and if the alg
in question is broken in the near future in a ciphertext-only
attack then the result was the same as no confidentiality,
and was (post-facto but still in fact) not "better" security,
as per the OS design pattern. The nearer the "near future" the
more this applies. One might even meet people who might
speculate that the "near future" for academic cryptographers
could be the recent past for some government cryptographers.

So, it is entirely consistent to both promote OS and deprecate
RC4 in TLS if the WG chairs declare this has rough consensus.

I guess questioning the proximity of the "near future" in the
above argument is reasonable, but if, as I believe, the crypto
folk all tell us RC4 is now definitely past its sell-by date
then it's time for an RFC that deprecates that so that the
sensible use-by date hasn't yet again gone flying by with us
having said nothing. (And bear in mind that RFCs and BCPs are
nowhere near as normative as the sell-by date on your local
litre of milk;-)

Cheers,
S.


>