Re: [TLS] Encrypt-then-MAC again (was Re: padding bug) (Martin Rex) Sat, 30 November 2013 01:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5328B1AE29F for <>; Fri, 29 Nov 2013 17:45:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TYXdTq5OI61Z for <>; Fri, 29 Nov 2013 17:45:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0BE0B1AE267 for <>; Fri, 29 Nov 2013 17:45:00 -0800 (PST)
Received: from by (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: <>
To: Watson Ladd <>
Date: Sat, 30 Nov 2013 02:44:49 +0100 (CET)
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: <>
From: (Martin Rex)
X-SAP: out
Cc: "<>" <>, Peter Gutmann <>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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