Subject: [TLS] padding bug (was: Re: Requesting feedback on TACK draft)

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 07 Sep 2013 20:59:20 -0600

[old thread alert!]

On 7/1/13 3:02 AM, Lewis, Nick wrote:
>> While people are looking at that, there's also the
>> encrypt-then-MAC draft, 
>> http://www.ietf.org/internet-drafts/draft-gutmann-tls-encrypt-then-mac-03.txt,
>>
>> 
which has been stable for about as long, has already been deployed by
>> several vendors, and for which TLS extension 0x10 has been de
>> facto claimed, so it'd be good to get this published to
>> legitimise the use (and to document what's already being deployed
>> in production).
> 
> As I recall there were three proposals for resolving the padding
> bug in TLS
> 
> 1.       An extension for Pad First (i.e. padding before an
> otherwise standard TLS mode of operation)
> 
> 2.       An extension for Encrypt-then-MAC (i.e. this draft)
> 
> 3.       The replacement of each existing cipher suite with an 
> equivalent AEAD one
> 
> Was any consensus achieved as to the best approach?

I never saw further discussion on this topic. Are there I-Ds for each
approach? #3 seems onerous to me (and doubling the number of cipher
suites doesn't seem like a desirable outcome), and as far as I can
tell there's no specification for #1. Although I am not a TLS expert,
the Encrypt-then-MAC I-D referenced above seems reasonable, it neatly
solves a real-world problem, and we have running code; thus IMHO
formalization of this approach deserves to be considered in the WG.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dr Stephen Henson <[email-masked]>
Date: Sun, 08 Sep 2013 13:07:46 +0100

>> Was any consensus achieved as to the best approach?

I can add a data point to this. I spent an afternoon implementing this (i.e.
the encrypt then mac draft) a while ago in OpenSSL. It was pretty easy to do
and interoped fine with the test servers.

I'll make it available as an experimental feature in OpenSSL master branch.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Dr Stephen Henson <[email-masked]>
Date: Sun, 08 Sep 2013 14:47:04 +0100

> I'll make it available as an experimental feature in OpenSSL master branch.

Well I've added this and spotted a problem. The draft extension value (0x10)
clashes with the draft value used in the ALPN specification.

Steve.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 08 Sep 2013 16:25:28 +0200

> formalization of this approach deserves to be considered in the WG.

It is important when trying to solve an issue not to introduce new
issues. The current proposal for #2 unfortunately does not take into
account known counter-measures for key recovery attacks in MACs (see [0]).

regards,
Nikos

[0]. http://www.ietf.org/mail-archive/web/tls/current/msg09520.html

---

From: Ben Laurie <[email-masked]>
Date: Sun, 8 Sep 2013 18:57:35 +0100

> clashes with the draft value used in the ALPN specification.

Given that the ALPN draft apparently has an allocated number, can we get
one allocated to this I-D?

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Sep 2013 06:01:02 -0700

Ben,

Generally, we're not doing advance code point assignments for documents
that haven't been accepted by the TLS WG.

Of course, this naturally raises the question of whether this document will
be accepted by the TLS WG. However, as I think recent discussion indicates,
there are a number of proposed approaches and there isn't really consensus
to adopt this particular one (especially in view of the increased adoption
of existing
mechanisms such as GCM). If someone (Peter? You?) wants agenda time
to argue for this particular approach instead of others, we're happy to
have the
discussion in YVR. This of course also applies to proponents of other
approaches.

Best,
-Ekr

[As Chair]

On Sun, Sep 8, 2013 at 10:57 AM, Ben Laurie <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Alfredo Pironti <[email-masked]>
Date: Mon, 9 Sep 2013 15:15:41 +0200

On Sun, Sep 8, 2013 at 4:59 AM, Peter Saint-Andre <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [old thread alert!]
>
> tell there's no specification for #1.

Approach #1 is defined in
http://tools.ietf.org/html/draft-pironti-tls-length-hiding-01 and we
have a couple of implementations for it. The main purpose of the I-D
is to provide means to conceal the payload length within TLS
fragments; however, a valuable byproduct is to also eliminate the
recent padding oracle attacks. The I-D applies to all currently
defined ciphers (block, stream, and AEAD). I'd like to hear your
comments about it.

Best,
Alfredo

---

From: Ben Laurie <[email-masked]>
Date: Mon, 9 Sep 2013 14:31:10 +0100

> discussion in YVR. This of course also applies to proponents of other

I'm not planning to be at YVR, what happened to using the mailing list for
discussion?

So, in favour of the WG adoption this I-D:

1. Nothing in this I-D prevents the adoption of other approaches.

2. If fixes the problem for all versions of TLS and SSLv3.

3. I've seen no objection that makes any sense. One objection I have seen
was that it "may not protect from key-recovery in a weak MAC construction"
- firstly, I am not aware of any such constructions in use in SSL/TLS, and
secondly, if there are any, it would be trivial to deprecate their use in
conjunction with this extension.

How about we take a vote?

Note, BTW, that unless convinced otherwise, we intend to implement this in
OpenSSL (it went into master yesterday), so you can consider that a vote in
favour :-)

>> On 8 September 2013 14:47, Dr Stephen Henson <[email-masked]
>> > wrote:
>>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 09 Sep 2013 17:10:53 +0300

Hi Eric,

I don't see draft-sheffer-tls-bcp as competing with this approach. I see 
the BCP as an interim solution that allows users to improves their 
security posture today, while the WG works on TLS 1.3 and/or on 
extensions that enable us to go back to a wide selection of available 
ciphersuites.

Thanks,
	Yaron

On 09/09/2013 04:01 PM, Eric Rescorla wrote:
> to adopt this particular one (especially in view of the increased
> adoption of existing
> On Sun, Sep 8, 2013 at 10:57 AM, Ben Laurie <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>
>     On 8 September 2013 14:47, Dr Stephen Henson
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>     Given that the ALPN draft apparently has an allocated number, can we
>     get one allocated to this I-D?
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 9 Sep 2013 14:10:18 +0000

>defined ciphers (block, stream, and AEAD). I'd like to hear your

Two comments, one on Approach #1, the other on Approach #2:

1. There is some formal support for the "Pad-then-encrypt-then-MAC"
approach being used in the above Approach #1 in the following paper:

Kenneth G. Paterson and Gaven J. Watson

Authenticated-Encryption with Padding: A Formal Security Treatment
Cryptography and Security: From Theory to Applications

Lecture Notes in Computer Science Volume 6805, 2012, pp 83-107.

http://link.springer.com/book/10.1007/978-3-642-28368-0

See in particular, Theorem 8 in the paper.

Unfortunately, this paper is behind Springer's paywall. For those on the
list without access, you can access the same content in Chapter 5 (Theorem
5.6, page 96) of Gaven Watson's Ph.D. Thesis, available here:

http://www.isg.rhul.ac.uk/~kp/theses/GWthesis.pdf

2. Approach #2 is well supported by theory and is more cryptographically
robust (in the face of bad implementations), provided the involved MAC
algorithm is strong enough.

I briefly reviewed the literature for the state-of-the-art on attacks
against HMAC-H for hash algorithm "H". (See for example
http://www.di.ens.fr/~fouque/pub/crypto07b.pdf, and later papers by L.
Wang et al. at Eurocrypt 2008, by X. Wang et al. at Eurocrypt 2009, plus
more recent work, e.g. Peyrin et al. at Asiacrypt 2012.)

In TLS, we essentially have H = MD5, SHA-1 or SHA-256.  In view of the
literature, of these, I'd recommend deprecating MD5 as the hash if
Approach #2 were to be adopted: current attacks do not seriously threaten
it, but taking a fairly conservative approach seems appropriate here.

Best wishes,

Kenny

---

From: Ben Laurie <[email-masked]>
Date: Mon, 9 Sep 2013 15:19:33 +0100

On 9 September 2013 14:31, Ben Laurie <[email-masked]> wrote:

> was that it "may not protect from key-recovery in a weak MAC
> construction" - firstly, I am not aware of any such constructions in use in
> SSL/TLS, and secondly, if there are any, it would be trivial to deprecate
> their use in conjunction with this extension.
>

I am reminded that we don't vote - so I guess I should rephrase this as -
"so, should we adopt this I-D?".

>>> On 8 September 2013 14:47, Dr Stephen Henson <
>>> [email-masked]> wrote:
>>>

---

From: Adam Langley <[email-masked]>
Date: Mon, 9 Sep 2013 10:42:46 -0400

> 2. If fixes the problem for all versions of TLS and SSLv3.

The cost of making any change to TLS is mostly equal to any other,
since the bulk of the cost is in deployment. Using an extension to
negotiate encrypt-then-MAC is a simple change, but it still leaves us
with CBC mode. On the other hand, AES-GCM left the station some years
ago and has a clear head start.

AES-GCM does, currently, depend on TLS 1.2, which is proving to be a
pain to deploy on the public Internet as a client, but we'll get there
soon.

I don't believe that this change solves the problem for SSLv3 as SSLv3
doesn't have extensions and so cannot negotiate it. Once AES-GCM is
running I'm hoping to simply define those ciphersuites all the way
down the versions in order to solve version downgrade issues.

Having an alternative to AES-GCM is certainly valuable, but I don't
want it to be AES-CBC. I think the prior discussion around
Salsa20/Chacha20 and a polynomial MAC is the most promising direction
for that.

I've no objection to this ID, but nor am I esp excited by it.

Cheers

AGL

---

From: Ben Laurie <[email-masked]>
Date: Mon, 9 Sep 2013 15:47:46 +0100

> Salsa20/Chacha20 and a polynomial MAC is the most promising direction

+1. Let's do that, too.

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 09 Sep 2013 15:49:40 +0100

> 2. If fixes the problem for all versions of TLS and SSLv3.

That to me is a very strong point in its favour. There have been weaknesses
affecting just about every ciphersuite with the exception of GCM mode, which
needs TLS 1.2. I'd love it if everyone moved to TLS 1.2 in the near future but
realistically that isn't going to happen. All manner of interop headaches
arrived with broken implementations when TLS 1.2 support was added to OpenSSL
and we still get frequent reports. Even with TLS 1.2 I'm uneasy about there
being only one symmetric cipher mode left.

I can add a few additional points in favour of this draft.

The signalling approach taken is similar to the one adopted with the secure
renegotiation (RFC5746), with the exception that extension intolerant servers
will choke. If we really care about those another signalling ciphersuite could
always be added.

I particularly liked the ease with which this could be implemented in OpenSSL
(Peter had similar experiences with Cryptlib). It took me just a few hours and
would've been less if some unfamiliar code hadn't been added recently:
ironically to address the "Lucky 13" attack.

It required no new APIs and it should work seamlessly with existing
applications. That's very important for a library if you have a large existing
code base.

One negative point relates to cryptographic hardware or software optimisations
(where you have an efficient or atomic way to handle record decryption) but I
think this will apply to other solutions too. Anything that needs to address
"Lucky 13" may have already hit this anyway.

On the particular point of addressing "Lucky 13" that attack was a real headache
for FIPS 140 compliance. Reimplementing algorithms at a low level to be constant
time will typically require revalidation with considerable expense and delays. A
partial (but far from perfect) mitigation was chosen as a compromise. If this
draft was adopted that would not be a problem any more as the existing validated
algorithm implementations could be used.

Steve.

---

From: Nico Williams <[email-masked]>
Date: Mon, 9 Sep 2013 10:34:00 -0500

Sure SSLv3 can negotiate this, using signaling cipher suite numbers.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 09 Sep 2013 17:53:12 +0200

> I'm not planning to be at YVR, what happened to using the mailing list for
[...]

> conjunction with this extension.

Unfortunately all algorithms are strong until the point they are broken.
We currently have HMAC-MD5 and while a key recovery attack does not
exist yet, I don't think anybody could rule-out such a development. What
about HMAC-SHA1?

Why not protect against future key recovery attacks by truncating the
MAC? After all IPSec does truncate the MAC to 96-bits for exactly the
same reason (see RFC2104 Section 5: Truncated output). Using the
existing good practices is a good thing.

regards,
Nikos

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Mon, 9 Sep 2013 12:08:07 -0400

>> Salsa20/Chacha20 and a polynomial MAC is the most promising direction

+1 on both.

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 24 Sep 2013 16:30:13 +0200

> approach being used in the above Approach #1 in the following paper:

I think here you meant "Pad-then-MAC-then-encrypt".

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 24 Sep 2013 14:43:01 +0000

>I think here you meant "Pad-then-MAC-then-encrypt".

Yes, thanks for the correction.

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 25 Sep 2013 08:28:59 -0700

> Salsa20/Chacha20 and a polynomial MAC is the most promising direction

All of the above matches my position as well. I don't see a lot of long-term
future in CBC-based cipher suites within browsers except as a legacy
mechanism. For example, we (Mozilla) have already decided not to offer any
SHA2- or SHA3- HMAC CBC cipher suites in Firefox, even when we enable TLS
1.2 and even though our TLS implementation already implements SHA256-HMAC
cipher suites. Adam's recent changes to NSS and OpenSSL have demonstrated
how to implement the existing encrypt-then-MAC construction in a way that
addresses the most acute known issues with the current CBC construct in TLS.
AES-GCM and soon new side-channel-free AEAD cipher suites (probably based on
Salsa/ChaCha) provide alternatives for implementations to avoid the CBC
construct altogether.

The downgrade issue only affects incorrect implementations of TLS like ours
(Firefox and other browsers); I think that the implementers of these
problematic products are best off working on a more general solution to the
downgrade issue, instead of encouraging more one-off workarounds for it. We
should focus our effort in this area to standardizing the side-channel-free
AEAD cipher suites and on verifying interoperability of AEAD cipher suites
(AES-GCM and new constant-time ones) even when the protocol version
negotiated on the wire is less than TLS 1.2. If we can't make that work then
we can re-consider our options.

> I've no objection to this ID, but nor am I esp excited by it.

Though I don't have any intentions to deploy it in Firefox at the current
time, I also have no objections to this ID, and in particular I encourage
the assignment of an extension ID for it if work is going to continue on it.
More generally, I think we should lower the bar for getting an extension ID
to "somebody has written a document describing what it means that isn't
completely crazy." I am not even sure that the "that isn't completely crazy"
qualifier is necessary. WHATWG asks that people register link relations
(e.g. "foo" in "<a rel=foo>") by simply editing a wiki, and that hasn't
caused any problems in practice.

I know there exist TLS implementations that aren't browsers and I am biased
towards considering browsers' needs over others. But, I think it is worth
considering how likely it is that this will be adopted by browsers when
considering if/how to move forward with it.

Regarding the particulars of the ID:

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. Also, the Chromium team experienced interop issues due to
the negotiated compression algorithm being part of the session state. Based
on that experience, I would expect interop similar issues if this were made
part of the session state.

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. The
draft cites Krawczyk's paper for motivation but Krawczyk's paper says that
there is nothing to worry about as long as the encryption mode is CBC,
right?

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

---

From: [email-masked] (Martin Rex)
Date: Thu, 26 Sep 2013 00:17:48 +0200 (CEST)

Brian Smith wrote:
> extension should be connection-level, not session-level.

The reason why this draft needs to be complex, is that the TLS
protocol is signficantly underspecified for rehandshakes (aka renegotiation).
rfc5746 fixes only the renegotiation security vulnerability,
it does not remove all of the underspecifed areas.

When a paricular PDU content change is part of a TLS cipher suite
and negotiated through the cipher suite ID, then the PDU change
from current to new will happen with "ChangeCipherSpec" (seperate
for each direction of the communication).

PDU changes based on TLS protocol version and based on TLS extensions,
however, usually apply to ServerHello already.  There currently
is also no distinction between changes to Handshake message PDUs
(or addition, insertion or reording of Handshake message PDUs),
and changes to the Record Layer PDU -- the latter being subject of
Peter's proposal to fix the mac-pad-encrypt for Blockciphers with CBC.

Personally, I since believe it would be sensible to specify/define at
the TLS protocol level that any changes to the record layer PDU,
_independent_ of how they're negotiated (cipher suite, compression algs,
TLS extension) ought to universally apply to the first message following
ChangeCipherSpec.

Currently, this is undefined/unspecified in TLS.

Question to implementors:  The GenericBlockCipher PDU for TLSv1.0
and TLSv1.1 differs.  Do you know what your implementation currently
does should the TLS protocol version changes on a rehandshake/renegotiation
between TLSv1.0 and TLSv1.1 (up or down), why it behaves like it does,
and where this is specified?  ;-)

-Martin