Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

Wan-Teh Chang <> Tue, 03 December 2013 03:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0F1511ADBC7 for <>; Mon, 2 Dec 2013 19:58:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GkuroNm4Bzd0 for <>; Mon, 2 Dec 2013 19:58:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c02::22c]) by (Postfix) with ESMTP id EAA491AD986 for <>; Mon, 2 Dec 2013 19:58:20 -0800 (PST)
Received: by with SMTP id w20so9429535vbb.3 for <>; Mon, 02 Dec 2013 19:58:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=j1ZqsEXhJpZkYyX3QF8UU5RXWspnOUiiJzk/zLVTlS0=; b=j7idh4zsQ9PD/jrUuoVPcTcs1UuqIYy2T3LvymEGq1n7yiUekk6WhfW9j5tCWt3ugS vBNImbmXhl1B7fIPDD5uso7HhWLnf9Ng9goOcPkaI4GVAJWlGqz323aqSXQTQ2l8II6W r4iJcCVpKm3xgGJ751wIrvehMVA1F0oneWPZ01koQWnYJghzUzUkUYqEFn5xBLORKnK/ lR8RfbTNIDJR5Q/nK9jRuvuXFAwKML6FPA6JkhubXio2GKBoOsR6XocsaA4X4dNn+vEg V2V2itqawmK0NySzcuycx9X5LWeHBBlpiMaO2s+Gx0c7ss5fSED9pu0fH27RibqycQs/ 1PMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=j1ZqsEXhJpZkYyX3QF8UU5RXWspnOUiiJzk/zLVTlS0=; b=EXh/PIX9xp7kOHukHr1AB1lh0KmsnlAa13mggB6VzynQ2JJ/AbHnLALteyTtjtCxWr VWq3J9QPhIhC4jjkSPRpjDSWM9xXAGEPKcnGQqUSJqy/QFpLgfGGdTHg9N0DxgnYjmw6 ZrS7YhA64Cw463uFM7+hcw4L/MAx1dwRiHa/04PVFO84Jz81EAA0Bej3qFedAsR0ckmI P5LVxPxCXeuVPCmEa1C6BbsWo/fmLd1+GIHuLiPTsMnMXR3x798Dsd2P0fyIXlQAD1fL cuDsFEj62UVAWgSSAPbUfKW1zqC+nkc53Ww9Jji8IgIpFHvMQiKCtmioxkUeX6w5gTOy eZjg==
X-Gm-Message-State: ALoCoQmsryWr4Zmw9jPsLNyM5UGb0WasFw6j5BVeQyJmRzv9wTkLRZkzcfvgYERSG64BrT5/jEqfdBGi2NAkQcUKiK9TwXpoimc6BYdxyaQTEEbrJB3FnMWS7YW2OgtRR3ctOzsrhe0R6cxTsreKEcbhAPJHIBKJLbtH0zGdYtMnHtceV8uigW4R9qs9gkY/bV0Ryrj4Q8mq
MIME-Version: 1.0
X-Received: by with SMTP id dr6mr4817587vcb.19.1386043098143; Mon, 02 Dec 2013 19:58:18 -0800 (PST)
Received: by with HTTP; Mon, 2 Dec 2013 19:58:17 -0800 (PST)
In-Reply-To: <>
References: <1385826600.11639.25.camel@aspire.lan> <> <> <> <>
Date: Mon, 2 Dec 2013 19:58:17 -0800
Message-ID: <>
From: Wan-Teh Chang <>
To: "" <>
Content-Type: text/plain; charset=ISO-8859-1
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: Tue, 03 Dec 2013 03:58:22 -0000

I am a programmer working on the NSS crypto libraries. Here are my
thoughts on this issue.

1. Since TLS 1.0 is widely deployed, we don't need to fix this issue
for SSL 3.0. This will avoid the need to add another SCSV.

2. I prefer a TLS extension that changes how CBC block ciphers work,
rather than adding new AEAD ciphers based on CBC-HMAC. (We already
have too many cipher suites.) In addition, CBC block ciphers should
work in this new way by default in TLS 1.3.

An argument for adding new AEAD ciphers based on CBC-HMAC is that it
simplifies testing. The extension-based solution essentially forks
every TLS version and increases the number of combinations that need
to be tested.

3. I took a look at the TLS/SSL implementation in NSS. I believe that
the EtA and pad-MAC-Encrypt proposals should require similar amount of
change to the NSS source code.

Ignoring the details of padding, It boils down to reordering the
operations this way:
    MAC-pad-Encrypt => pad-MAC-Encrypt
vs. reordering the operations this way:
    MAC-pad-Encrypt => pad-Encrypt-MAC

So the assertion that pad-MAC-Encrypt requires a smaller patch doesn't
seem to be true for NSS. Caveat: it's possible that the arguments
passed to the three operations need more adjustments when the
operations are reordered in one way. I didn't look into that.

4. The TLS/SSL implementation in NSS performs the padding itself
rather than letting the underlying encryption function do the padding.
This means the pad-MAC-Encrypt proposal won't make things more
difficult for NSS in this aspect.

Wan-Teh Chang