Re: [TLS] Would this fix RC4 again? (was Re: Encrypt-then-MAC again (was Re: padding bug))

Watson Ladd <watsonbladd@gmail.com> Thu, 14 November 2013 04:48 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A0921E81A2 for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 20:48:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6BUBJdTFJhs for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 20:48:43 -0800 (PST)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 20FD221F9FF3 for <tls@ietf.org>; Wed, 13 Nov 2013 20:48:35 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id t61so1349739wes.30 for <tls@ietf.org>; Wed, 13 Nov 2013 20:48:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tUmOlXAFgPRPFTD/mSqhvTiJJ6j2S6f2cPlii33RKIY=; b=GvapaLSOCzJzPAPaC7/bT+OSMkV0sxSB41wLNqqgPduqdAhb3ylCYYWxlDi23rRcU4 2dmaFj19YQvbJ2lTgoAbPHHqnj6VS1UCxp+kak4QEZGh5Ny18ppnUDng7ZuBgN208kfG ynwHAG+FjMkrgFpoaCZ6x9LGOLk4KC+zXtN+sLrYqMIGnNTagPnSylYnJv6cYVIc3utu /A8HXUd81DNaOD96Ok7aMcl23p4w70Ip+NAkqZ3mQ2F3hdtruJ00kyiCdR3J10xTmrQr HIBfbmKw+dmdNod6ywfdMo1Q+GEcxYFWeKb8HsE87CSZAwVBrv3SfbJ4lFlMy0c251Z5 RsBw==
MIME-Version: 1.0
X-Received: by 10.180.78.132 with SMTP id b4mr459014wix.0.1384404515027; Wed, 13 Nov 2013 20:48:35 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Wed, 13 Nov 2013 20:48:34 -0800 (PST)
In-Reply-To: <52844E54.8000606@pobox.com>
References: <20131112222944.2B0FD1AA82@ld9781.wdf.sap.corp> <1384400970.2092.7.camel@aspire.lan> <52844E54.8000606@pobox.com>
Date: Wed, 13 Nov 2013 20:48:34 -0800
Message-ID: <CACsn0c=d+tsDLcJFWpcDpbQdPRBNy3WERCQzepNWsyJfp2-cWA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Michael D'Errico <mike-list@pobox.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Would this fix RC4 again? (was Re: Encrypt-then-MAC again (was Re: padding bug))
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Nov 2013 04:48:43 -0000

On Wed, Nov 13, 2013 at 8:15 PM, Michael D'Errico <mike-list@pobox.com> wrote:
> Nikos Mavrogiannopoulos wrote:
>>
>> On Tue, 2013-11-12 at 23:29 +0100, Martin Rex wrote:
>>>
>>> You proposal adds the padding at the beginning only.  Since the
>>> problem exhibited by RC4 is inherent to any XOR-encryption with
>>> a pseudo-random-pad, AES-CCM, AES-GCM, etc. I would make such an
>>> extension use random fraction, random content, authenticated padding
>>> on both sides of the plaintext, with a combined minimum padding length of
>>> at least 16 bytes, in order to mitigate statistical attacks on
>>> any bias that may be found in the pseudo-random-pad.
>>
>>
>> The above draft does:
>> 1. prevent padding oracle attacks
>> 2. hide the length of the plaintext
>>
>> What you propose there is having the plaintext appear and finish in an
>> unpredictable position. That's an interesting approach, not handled by
>> the draft above.
>>
>> In simple terms you're asking for more bells and whistles :)
>
>
> If I recall correctly from DJB's paper, the problem with RC4 is bias in
> the first 256 or so bytes of the key stream.  Would it be possible to
> "fix" RC4 using this extension?  Simply insert a random amount (at
> least 256 bytes) of pseudo-random padding at the beginning of the first
> record sent using an RC4 cipher suite?
You recall incorrectly. The bias DJB et al. discovered was not the bias that
explains why RC4 should not be used: the Fluhrer-McGrew bias in all
bytes dooms RC4.

We have a perfectly good mode: AES-GCM. We should use it.
This whole topic is a waste of time: For a good stream cipher it does nothing,
for a bad stream cipher it also does nothing.

Let's talk about the real problems: slow deployment of TLS 1.2, Suite
B not being used extensively,
reducing round trips, lack of protection against downgrades, TCP shenanigans.
> Mike
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> 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