Re: [TLS] padding bug

Peter Gutmann <> Thu, 26 September 2013 05:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DD8311E8135 for <>; Wed, 25 Sep 2013 22:10:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OiCheDOQCr37 for <>; Wed, 25 Sep 2013 22:09:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9443421F9E95 for <>; Wed, 25 Sep 2013 22:09:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=uoa; t=1380172196; x=1411708196; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=gzYD1rOt1OqJYiOTcxTJEqCKbEzR8jzqIt1XPnLvE08=; b=Yvl7/mBDqfn8A3n0Uz8tgTn5579yFRE8yN+Ev8BaHbCMOnikJe+cgEbw 4sLfU9DIq7ue327E+ZzXC24JxjX4L1IzBeI8nnTMaUk8HlVApqxyUBAvM tnQCUKG5GyKyW/JzWA+wvFVEnqn4Y4hWYBHiHlNDJ+rZi1bSq7t6WNt63 I=;
X-IronPort-AV: E=Sophos;i="4.90,982,1371038400"; d="scan'208";a="214292756"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 26 Sep 2013 17:09:54 +1200
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 17:09:53 +1200
From: Peter Gutmann <>
To: "<>" <>
Thread-Topic: [TLS] padding bug
Thread-Index: Ac66dmh5e0o65odvRG+KdOIeZQAqbQ==
Date: Thu, 26 Sep 2013 05:09:52 +0000
Message-ID: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] padding bug
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Sep 2013 05:10:03 -0000

Brian Smith <> writes:

>Section 3.1. (Rehandshake Issues) seems overly complex. I think this
>extension should be connection-level, not session-level. Imagine a browser
>that contains a preference that controls whether we support the extension.
>It would be best if we could create a session with that preference set to
>one value and then resume that session with the preference set to the
>opposite value. 

Uhh, isn't that a security problem if you can rehandshake and turn EtM

(I don't have much of an opinion in this area since my code doesn't do
rehandshakes because I consider them too problem-prone, but if people 
have concerns over this it'd be good to discuss them on the list.  My 
solution is just "don't do that, then").

>Section 4 (Security Considerations) would be better if it listed specific
>ways that the encrypt-then-MAC construct is currently known to be better
>than state-of-the-art (i.e. Adam's constant time) implementations of the
>MAC-then-encrypt construct, in the context of TLS's CBC cipher suites. 

I didn't do that both because it'd involve tracking down a decade's worth 
of attacks on TLS to document them, and would be out of date as soon as
the next attack on MAC-then-encrypt is published.