Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00

Alyssa Rowan <akr@akr.io> Fri, 08 August 2014 13:49 UTC

Return-Path: <akr@akr.io>
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 D36551B29B9 for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 06:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 vjh6_gyZDlKx for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 06:49:45 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0BB1B29E8 for <tls@ietf.org>; Fri, 8 Aug 2014 06:49:45 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <20140808133628.7C9931ADFC@ld9781.wdf.sap.corp>
References: <20140808133628.7C9931ADFC@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Alyssa Rowan <akr@akr.io>
Date: Fri, 08 Aug 2014 14:49:39 +0100
To: tls@ietf.org
Message-ID: <93462f83-ffff-4ad4-9a5b-89d3bbc1497c@email.android.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bdICSaZa1uG9XLqmGJFGc4cA-Lw
Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00
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: Fri, 08 Aug 2014 13:49:48 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 8 August 2014 14:36:28 BST, mrex@sap.com wrote:

>The RC4 cipher suites are still stronger than the EXPORT40 and EXPORT56
>cipher suites, because for the latter, even one singular session can
>be successfully attack and *completely decrypted* in most cases,
>whereas
>the weaknesses currently known for RC4 cipher suites allow an attacker
>to recover only the plaintext equivalent of a static
>"disclosing authentication" (password or token) after 2^20+ TLS
>session.
>
>
>I therefore object to the Bullets 2 & 3 of section 2,
>(I'm OK with bullet 1):
>
>
>
>   2.  Changes to TLS
>
>     Because of the deficiencies noted in Section 1:
>
>   o  TLS clients MUST NOT include RC4 cipher suites in the ClientHello
>        message.
>
>   o  TLS servers MUST NOT select an RC4 cipher suite when a TLS client
>        sends such a cipher suite in the ClientHello message.
>
>     o  If the TLS client only offers RC4 cipher suites, the TLS server
>        MUST terminate the handshake.  The TLS server MAY send the
>        insufficient_security fatal alert in this case.
>
>
>It should be left to the local policy of the server whether to agree
>to the use of an RC4 cipher suite rather than fail the connection.
>
>Servers should NEVER let the client-side ordering of cipher suites
>in ClientHello take precedence over the servers' preference,
>and RC4 cipher suites, similar to EXPORT40 and EXPORT56 cipher suites
>should never take precedence over stronger cipher suites that client
>and server have in common, just because they happen to appear earlier
>in the list in ClientHello.
>
>
>Especially in the Web, where access to information is often available
>through HTTP and HTTPS, a policy like the above (when adopted) would
>cause MORE communication to be performed in plaintext.
>
>There currently exists *no* known attack against the integrity
>protection of the TLS handshake, so this looks primarily like an
>attempt to promote "planned obsolesence", and a poor excuse for
>Microsoft to actively break interop with Windows XP (and potentially
>other installed base).

(Apologies if this brief message comes across abrupt/rude, as I'm pressed for time right now. Please infer due respect.)

Strongly disagree with your proposed change Martin, which fundamentally goes against the wide MUST NOT use RC4 consensus already confirmed in previous calls. I feel the draft language should stay just as it is.

Given the discussions and meetings already supporting that consensus, I have to ask: why are you proposing this big change so late in support of *any* continued use of a known-weak cipher?

XP is out of support and should definitely not be considered as a blocker.

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJT5NVyGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6ZtIQAK2+xpNdI8wCIUQqTVzxSCoiYiAMpSWnsQZBAmGgSaj11nsCagRm
r4GLMqqm9Q9m1Dx34QiPb1nVV+aFutQpAhn9j7ElSRLIYSOhl67H30CmJ/3MS/Wh
fOnL44lHiMDtj1E/thWO+iW5UvMcg4VWfm0N5fV6o2vC4kOJ+alPvvcGt7oJ23ZQ
lH4cBKzqcgofaYEP58vHPVC08I6LEAdMQ+XkBCovW38J1lJRtCRrnctjpPaFS9kB
615+te7vQChH0hFeFPZ7MgrXUh3btfc7PQPsKf4HtZ6FURrA9DQkk/zwdKWzLd3X
uRTQO5NHdr/HwP2CStF9yP21CezewV46wpBH+QpJ/VGwbYdMdFWyrIy/bFwEZJuV
46Gz382d89Y3O0487V8+Emd1jl6ASZX1d96XYA0r/8QPlwMewUxljmfNBwl6oDam
oIhwK7fFx3HL+R4DY+87beR00Y4lR+3DeRAlHj75c8bWKS6LVq4/FEg2RCAfn9DE
Rk86eNVlfzFGtAj5LzCa3ROc8RzpycN91LMBPs6UuPLdTghDIzTIGkeQgnn+QAy1
hrs8VVak4m/pWR+lkn0/UcmZDlPtJmVTQDxfIO6DFokwk5gkvPNzngxdB/SNZ1FR
vrr8z2XKTDajoeSgrKs5p7GxlWFJbxWnGjtvGfre5e/WiKzvmc4w1m+t
=F8sW
-----END PGP SIGNATURE-----