Re: [TLS] RC4 deprecation path (Re: Deprecating more (DSA?))

Kurt Roeckx <kurt@roeckx.be> Sat, 19 April 2014 17:53 UTC

Return-Path: <kurt@roeckx.be>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F6E1A0057 for <tls@ietfa.amsl.com>; Sat, 19 Apr 2014 10:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id su_TlS_Kp8eZ for <tls@ietfa.amsl.com>; Sat, 19 Apr 2014 10:53:57 -0700 (PDT)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 62C0A1A0055 for <tls@ietf.org>; Sat, 19 Apr 2014 10:53:57 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 9684D1C23B3; Sat, 19 Apr 2014 19:53:52 +0200 (CEST)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 6950C1FE0214; Sat, 19 Apr 2014 19:53:52 +0200 (CEST)
Date: Sat, 19 Apr 2014 19:53:52 +0200
From: Kurt Roeckx <kurt@roeckx.be>
To: Michael D'Errico <mike-list@pobox.com>
Message-ID: <20140419175352.GA9090@roeckx.be>
References: <CACsn0cnZFScA1WnitpHH--6_Kd0spfLQvmvniyCSnUmvr8xVhg@mail.gmail.com> <20140419131019.GA29561@roeckx.be> <5352B328.1080006@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5352B328.1080006@pobox.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XfDE81oUXK0W84WGRar28-P6dmg
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] RC4 deprecation path (Re: Deprecating more (DSA?))
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 19 Apr 2014 17:53:59 -0000

On Sat, Apr 19, 2014 at 10:32:24AM -0700, Michael D'Errico wrote:
> Kurt Roeckx wrote:
> >
> >- Clients should not announce support for RC4 in their initial
> >  connection attempt, and only fall back to support it when the
> >  server says that there are no common ciphers.  (I'm not sure
> >  if a MITM can fake that response or not.)
> 
> Continue the handshake all the way through to the Finished messages
> to determine if a MITM has tampered with it.  This will only not
> work if the server is of the type that chooses RC4 no matter where
> it is in the client's cipher suite list.
> 
> Here's the message flow I'm thinking about:
> 
>     ClientHello (w/o RC4)      ----->
>                                <-----    Alert (handshake_failure)
> 
> close and reconnect:
> 
>     ClientHello (with RC4)     ----->
>                                <-----    ServerHello (RC4 chosen)
>                                          ..... continues
> 
> Place the RC4 suites at the end of the list so that the server will
> not choose them if it respects the client's preference.

Right, so an MITM could downgrade to RC4 in case the server
prefers RC4 over the rest in that case.


Kurt