Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
mrex@sap.com (Martin Rex) Sat, 30 November 2013 01:45 UTC
Return-Path: <mrex@sap.com>
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 5328B1AE29F for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 17:45:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 TYXdTq5OI61Z for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 17:45:01 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE0B1AE267 for <tls@ietf.org>; Fri, 29 Nov 2013 17:45:00 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAU1inMI019067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Nov 2013 02:44:49 +0100 (MET)
In-Reply-To: <CACsn0ckVhZV=JeQ10Uv9ESLvAO9C9V1or72-DqC6Vjh1cWm7aQ@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Sat, 30 Nov 2013 02:44:49 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131130014449.760781AB10@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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, 30 Nov 2013 01:45:03 -0000
Watson Ladd wrote: > > Something needs to be done about the issues of TLS. It's clear there > is no consensus on this list, but doing nothing is not an option. > Personally, driving to TLS 1.2 avoids the need to deploy a long series > of patches, as well as design fixes and analyze them. TLSv1.2 is a royal PITA for TLS clients, because it requires a reconnect fallback facility to be implemented by ***EVERY*** application caller client on top of TLS, ***PLUS*** every application caller will have to memorize the fallback for every destination or the latency will be a royal pain for every new handshake after the TLS session expires from the client-side TLS session cache (when client-side session caching is used at all. Client-side TLS session caching seems to be much less common in programmatic clients than I would have expected). In addition, that fallback reconnect subjects the caller to a downgrade vulnerability when those ciphersuites that are (apparently) considered secure or preferable can not be proposed&negotiated when doing a fallback reconnect. Bodo and Adam think the downgrade issue of fallback reconnects is sufficiently severe that it needs immediate Working Group action, whereas I believe it would be much more reasonable to make the negotiation of the desired security strength succeed even on a TLS-version-downgraded handshake, because it would benefit everyone, in particular the programmatic clients without a fallback reconnect facility, and it would give better results in the face of dense middle boxes. The proposed "Server please Abort on Downgrade detection" will lead to lots of end user nuisance, and the end user and IT help desk work around will be to disable TLSv1.1 & TLSv1.2 in the browser, both of which is squarely against the IETF spirit to promote interop. -Martin
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Peter Gutmann
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Eric Rescorla
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Watson Ladd
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Juho Vähä-Herttua
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Bodo Moeller
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Bodo Moeller
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Juho Vähä-Herttua
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Robert Ransom
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Watson Ladd
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Juho Vähä-Herttua
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Taylor Hornby
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Watson Ladd
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Alfredo Pironti
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Paterson, Kenny
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Alfredo Pironti
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Watson Ladd
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Alfredo Pironti
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Wan-Teh Chang
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Paterson, Kenny
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Paterson, Kenny
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Watson Ladd
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Peter Gutmann
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Peter Gutmann
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Peter Gutmann
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Peter Gutmann
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Trevor Perrin
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Watson Ladd