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

From: Peter Gutmann <[email-masked]>
Date: Thu, 28 Nov 2013 11:32:29 +0000

Michael D'Errico <[email-masked]> writes:

>In trying to figure out what's stalling the encrypt-then-mac draft

What's stalling the draft is that the WG chairs refuse to accept it, and
nothing else.  This is a simple, trivial fix for a decade-old problem that's
come back to bite us again and again, that several implementations have
already implemented, and that a straw poll on the list a while back indicated
had general support.  In other words the requirements for rough consensus and
running code was met some time ago.

Therefore, I propose a second straw poll to follow the earlier one:

 The WG chairs have refused to accept a draft containing a simple,
 straightforward fix to a serious problem in TLS' crypto, one that has rough
 consensus and running code.  I therefore propose a vote of no-confidence in
 the TLS WG chairs, since I have no confidence that they're acting in the best
 interests of TLS development and TLS users.

To get things started, I'll vote no-confidence in the TLS WG chairs.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Nov 2013 07:02:49 -0800

On Thu, Nov 28, 2013 at 3:32 AM, Peter Gutmann <[email-masked]> wrote:
> nothing else.

Peter,

This topic was discussed at the TLS WG meeting in Vancouver
(since you declined to attend, Joe Salowey provided a brief
description of the two options). Your proposed approach
had no support in the room. You can find the minutes here:

http://tools.ietf.org/wg/tls/minutes?item=minutes-88-tls.html

So, while there has been some support on the list, I don't
believe that this supports the claim that there is rough
consensus for this draft.

With that said, if you're unhappy with the performance of the
chairs, you should reach out to the Security ADs
([email-masked])

Best.
-Ekr
[Speaking as Chair]

---

From: Watson Ladd <[email-masked]>
Date: Thu, 28 Nov 2013 09:15:37 -0800

> consensus for this draft.
Where are the opponents on the list? Anyone can hum, but I would like
to see them
put their names and reasons down. I personally think we should have a
ciphersuitedammerung in which
everything but AES-GCM is depreciated, and adding encrypt-then-mac
isn't worth it, so I probably
would have opposed it: it adds complexity at no gain. Then again my
hopes have been crushed again and again.

But as chair you have failed consistently to ensure that the list
reflects the decision making process.
You are directly responsible for endorsing drafts with known security
issues, and have failed to articulate
a clear direction forwards for this WG. You have placed users and
their security below the convenience of vendors,
presiding over the expansion of a smorgasbord of options so that
everyone can claim to support TLS 1.2, without providing
an iota of security or interoperability. Anyone can extend TLS and get
your approval, so long as it doesn't improve
security or have a chance of actually getting used. (See SRP and PWD).
What have the past 14 years done for us in terms of improvements to TLS?
Sincerely,
Watson
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 29 Nov 2013 14:00:02 +0100

> > http://tools.ietf.org/wg/tls/minutes?item=minutes-88-tls.html

That page looks broken (garbled UTF-8?).  Try
http://www.ietf.org/proceedings/88/minutes/minutes-88-tls for a more
legible version (PDF).

> put their names and reasons down

Decisions at meetings can't silently override mailing list consensus, but I
think Eric felt that the meeting outcome merely reflected a lack of
consensus that he'd previously already got from the list -- see his
previous summary on this list here:

http://www.ietf.org/mail-archive/web/tls/current/msg10004.html

(That said, Nikos' complaint seems bogus to me.  Peter's proposal seems
fine from a security point of view -- as long as clients refuse to
unnecessarily roll back to SSL 3.0, e.g. using
draft-bmoeller-tls-downgrade-scsv-01 --, the question is just if it's worth
the extra complexity given the other options.)

Bodo

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 29 Nov 2013 16:23:29 +0100

> Decisions at meetings can't silently override mailing list consensus,
> but I think Eric felt that the meeting outcome merely reflected a lack
> of consensus that he'd previously already got from the list -- see his
> (That said, Nikos' complaint seems bogus to me.  Peter's proposal
> seems fine from a security point of view -- as long as clients refuse
> to unnecessarily roll back to SSL 3.0, e.g. using
> draft-bmoeller-tls-downgrade-scsv-01 --, the question is just if it's
> worth the extra complexity given the other options.)

I think there is some confusion over that. It was a suggestion rather
than a complain; and is not a stopper for such a draft. The fact that
MAC truncation is known to improve security (for HMAC-MD5 and
HMAC-SHA1), does not render non-truncation insecure (as many have
pointed out -including me - there are no known practical attacks against
HMAC-MD5 and HMAC-SHA1).

regards,
Nikos

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 29 Nov 2013 17:02:15 +0100

> than a complain; and is not a stopper for such a draft.

Thanks for clarifying!

> The fact that

It's also not actually a known fact that MAC truncation will improve
security.  While there are certain (hypothetical) advantages, there are
also certain (more concrete) disadvantages.  As the HMAC RFC puts it (RFC
2104): "The results in this area are not absolute as for the overall
security advantages of truncation."

Bodo

---

From: [email-masked] (Martin Rex)
Date: Fri, 29 Nov 2013 17:20:25 +0100 (CET)

> running code was met some time ago.

I've been thinking over this proposal for quite a while, and I've made
up my mind.  I'm now strongly opposed.

I'm perfectly OK with a solution for fixing the mac-pad-encrypt goof
in GenericBlockCipher PDU for all existing versions of TLS, but I'm
strongly opposed to moving the HMAC into the clear, and into particular
I am strongly opposed to put the HMAC into the clear for the
GenericStreamCipher PDU.

I'm going to prepare a proposal I-D to do exactly (and only) what
Serge Vaudenay had recommended in 2001, and what TLSv1.1 failed to fix,
change mac-pad-encrypt into pad-mac-encrypt for the GenericBlockCipher PDU.
When doing this, we can also consistently adopt the explicit random IV
(which can be implemented as a random confounder) to all versions of TLS.

Signaling of this PDU change will be through a new SCSV in ClientHello,
confirmation by the Server through a simple ServerHelloExtension, similar
to how signaling is done for rfc5746 (TLS renegotiation_info extension).

-Martin

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Fri, 29 Nov 2013 19:00:29 +0200

> On 29.11.2013, at 18.20, [email-masked] (Martin Rex) wrote:
> 

You have been quite clear about that, and I've got the impression that you are the only but very vocal opponent of encrypt-then-mac on this list. Although in GenericStreamCipher it offers no benefit, I still haven't seen a convincing argument about why encrypt-then-mac should not be used.

I'm sure you have good reasons for this opposition, so could you please explain them in one or two sentences. This excluding the "encrypting the HMAC makes it safer" argument, which might be true but as I understand is not well proven.

> to how signaling is done for rfc5746 (TLS renegotiation_info extension).

This might be the only way to solve this problem, but I must point out that SCSVs seem to be a solution for everything now. Browsers allow a version downgrade attack? Let's add an SCSV. The CBC handling is broken? Let's add an SCSV. How many SCSV hacks can we add?

Adding AEAD support for TLS <1.2 is a good idea and wouldn't require hacks, but I'm worried it wouldn't be adopted fast enough. Especially since CBC+HMAC AEAD ciphers that would be easiest to patch are impossible in TLS because of the way AEAD is implemented.

So I prefer fixing CBC first (with encrypt-then-mac unless otherwise proven) and then allowing AEAD in all versions to let people prepare for GCM in whatever version they use instead of trying to force TLS 1.2 upgrade with GCM, it clearly isn't working.

Juho

---

From: Robert Ransom <[email-masked]>
Date: Fri, 29 Nov 2013 09:26:06 -0800

On 11/29/13, Juho Vähä-Herttua <[email-masked]> wrote:
> You have been quite clear about that, and I've got the impression that you
> are the only but very vocal opponent of encrypt-then-mac on this list.

Nikos Mavrogiannopoulos has also been opposed to encrypt-then-HMAC.  I
don't know of any others.

> Although in GenericStreamCipher it offers no benefit, I still haven't seen a
> convincing argument about why encrypt-then-mac should not be used.
>
> I'm sure you have good reasons for this opposition, so could you please
> explain them in one or two sentences. This excluding the "encrypting the
> HMAC makes it safer" argument, which might be true but as I understand is
> not well proven.

"not well proven" is the wrong phrase here.  Marsh Ray solidly debunked it.

> Adding AEAD support for TLS <1.2 is a good idea and wouldn't require hacks,
> but I'm worried it wouldn't be adopted fast enough.

To put it even more bluntly: OS and hardware vendors will treat TLS
1.2 or AEAD support and an efficient-in-secure-software AEAD cipher as
new features, and sit on them for a few *years*.  TLS, and every
pre-1.2 TLS implementation in the world, needs a critical security
bugfix *yesterday*, and the only bugfix I see that is ready to be
deployed as such is draft-gutmann-tls-encrypt-then-mac.

Robert Ransom

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 29 Nov 2013 19:13:34 +0100

> don't know of any others.

It seems I'll have to repeat that. I don't oppose this draft. I prefer
an alternative [1], which was not mentioned in the IETF88 meeting. So if
the question would be AEAD (i.e, not a fix) or encrypt-then-mac, I'd go
with the latter. If the question is [1] or encrypt-then-mac I'd go with
the former.

> "not well proven" is the wrong phrase here.  Marsh Ray solidly

I don't quite understand that. No-one questioned his observations in any
point at any previous discussion. Please review them to understand where
I stand.

regards,
Nikos

[1].
http://tools.ietf.org/search/draft-mavrogiannopoulos-new-tls-padding-01

---

From: Watson Ladd <[email-masked]>
Date: Fri, 29 Nov 2013 10:23:43 -0800

> with the latter. If the question is [1] or encrypt-then-mac I'd go with
Why do you prefer this alternative?
AEAD is a fix, provided we deploy it. But that isn't happening for
whatever reason.
I suspect that we will soon learn that all fixes do not get deployed
for mysterious reasons.
Solution: get it right the first time.
> point at any previous discussion. Please review them to understand where
So if HMAC is only a universal hash then HMAC followed by counter mode
is secure, but
HMAC followed by CBC is secure up to a collision of the chaining
value. This analysis assumes
the HMAC falls in a block.

But remember HMAC is essentially H(k||H(k||m)). In particular if the
H(k||m) is a universal hash function,
and H(k||..) satisfies some sort of keyed security assumption (PRF for
fixed length?) HMAC is secure.

So the only way HMAC followed by encrypt is more secure than encrypt
followed by HMAC is if things
break in a really weird way.
Sincerely,
Watson Ladd

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Fri, 29 Nov 2013 20:20:29 +0200

> On 29.11.2013, at 19.26, Robert Ransom <[email-masked]> wrote:
> 

I understood his opposition was not strong, I think the last comment from him supports that.

> "not well proven" is the wrong phrase here.  Marsh Ray solidly debunked it.

I was probably being too careful with my words, not being a cryptographer myself. But let's change that to "based on current knowledge is debunked" :)

To correct myself a bit more, CBC+HMAC is possible in AEAD by modifying plaintext before encryption as in McGrew et al. draft, but that's not very relevant to the discussion.

> deployed as such is draft-gutmann-tls-encrypt-then-mac.

I agree with this, sounds quite likely.

Juho

---

From: [email-masked] (Martin Rex)
Date: Fri, 29 Nov 2013 21:17:14 +0100 (CET)

Juho Vähä-Herttua wrote:
> You have been quite clear about that, and I've got the impression that
> you are the only but very vocal opponent of encrypt-then-mac on this list.
> Although in GenericStreamCipher it offers no benefit, I still haven't
> seen a convincing argument about why encrypt-then-mac should not be used.

I'm from the "don't-fix-it-if-it-ain't-broken" camp.
And the less code needs to be changed to adopt some useful feature,
the more likely you will see it being adopted for patches/maintenance.
I have seen *ZERO* compelling reason for switching to encrypt-then-mac
in TLS.  And I'm not aware of *ANY* reason why we should touch/change
the GenericStreamCipher processing (which Peter's proposal does).

I also dislike (a) making a change to SSLv3/TLSv1.0 GenericBlockCipher
processing, but (b) leaving the predictable IV exploited by BEAST
unfixed, and essentially creating two seperate new GenericBlockCipher PDUs,
rather than just a single one for all that fixes all known problems.

> HMAC makes it safer" argument, which might be true but as I understand
> is not well proven.

The fact that GHASH must be encrypted is sufficient proof that an
encrypted MAC provides a better safety margin than a plaintext MAC.

MAC in the clear is only safe when the MAC algorithm is sufficiently
close to perfect.  We know painfully well that our hash algorithms
are *not* perfect, so I'm against taking chances, in particular
for the GenericBlockCipher PDU.

> This might be the only way to solve this problem, but I must point out
> that SCSVs seem to be a solution for everything now. Browsers allow a
> version downgrade attack? Let's add an SCSV. The CBC handling is broken?
> Let's add an SCSV. How many SCSV hacks can we add?

I think we should distinguish between "fixes" and "new features".
Fixes should be as small as possible (code-wise and limited to the
exact problem) so that they have a high chance of getting adopted
for patches/maintenance to the installed base.

Looking at how many new ciphersuites have been proposed over the years,
the number of SCSV proposals IMO pale in comparison.  Even the "silly
ciphersuites" in rfc5246 outnumber the current SCSVs:

(ciphersuites which, according to SP800-57 are non-sensical)

rfc5246:
      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256       = { 0x00,0x3C };
      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256    = { 0x00,0x3E };
      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256    = { 0x00,0x3F };
      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256   = { 0x00,0x40 };
      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   = { 0x00,0x67 };
      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256   = { 0x00,0x6C };

According to SP800-57, HMAC-SHA1 is perfectly sufficient for combination
with AES128, and this is even more true for encrypted HMAC-SHA1 with
TLS'es GenericBlockCipher PDU.

(btw. the one thing that confuses me about
 NIST SP 800-57 Part1 Rev.3 (July 2012) is that GHASH does not
 appear in Table 3 on page 65.)

> 
> Adding AEAD support for TLS <1.2 is a good idea and wouldn't require
> hacks, but I'm worried it wouldn't be adopted fast enough.

Partially true.  The footprint for AES-GCM code changes is so large
that it may not happen for code that is under maintenance, rather
than new products.  In particular, AES-GCM will probably require
FIPS 140-2 recertification, whereas a fixing the CBC padding may
not need a recertification (this probably depends on the software
module boundaries).

>
> Especially since CBC+HMAC AEAD ciphers that would be easiest to patch
> are impossible in TLS because of the way AEAD is implemented.

I'm sorry, I fail to follow.  CBC and AEAD seems to be two distinct
modes of encryption and somewhat of a contradiction to each other.

Were you thinking of AES in counter mode with HMAC as MAC?
AFAIK, this could be done with GenericStreamCipher instead.

> 
> So I prefer fixing CBC first (with encrypt-then-mac unless otherwise
> proven) and then allowing AEAD in all versions to let people prepare
> for GCM in whatever version they use instead of trying to force
> TLS 1.2 upgrade with GCM, it clearly isn't working.

Personally, I trust CBC+HMAC more than I trust GCM.
I have difficulties thinking of weaknesses of the cipher, that when
found, would always affect both CBC and GCM modes.  But not all weaknesses
that are fatal to GCM would also be fatal for CBC.

And we know that our algorithms are not perfect, and that NIST
didn't put much of a security margin into AES -- so little that
AES-256 is known to fall quite short of 256-bit security.

-Martin

---

From: Taylor Hornby <[email-masked]>
Date: Fri, 29 Nov 2013 13:34:20 -0700

> the GenericStreamCipher processing (which Peter's proposal does).

The quantity of code changes isn't all that matters. The complexity and
the elegance of the changes do too.

Often you can fix something with a one-line hack that makes the code
more confusing, or you can re-write the function and do it properly. I
suspect moving to pad-mac-encrypt instead of pad-encrypt-mac is more
like a one-line hack that would actually make implementation harder.
Most of the encryption APIs I've seen do the padding internally, where
you can't access it to compute the MAC.

Also: Won't you still have to use the padding to *find* the MAC in the
ciphertext, in order to check the MAC before you remove the padding? If
so, then a padding oracle is still possible.

[snip]

> for the GenericBlockCipher PDU.

I don't follow this logic. MAC functions are evaluated by letting the
adversary see MAC tags and yet still not being able to forge messages.
Making them public does not reduce their security as a MAC... otherwise
they AREN'T MACs.

[snip]

-- 
Taylor Hornby

---

From: [email-masked] (Martin Rex)
Date: Fri, 29 Nov 2013 22:09:40 +0100 (CET)

> the elegance of the changes do too.

I do not consider seperate new GenericBlockCipher PDUs (one for SSLv3+TLSv1.0
and a seperate one for TLSv1.1+TLSv1.2) particularly elegant, and neither
do I think that leaving the predictable IV in SSLv3+TLSv1.0 is sensical
when we _do_ change that PDU.

> more confusing, or you can re-write the function and do it properly.

> I suspect moving to pad-mac-encrypt instead of pad-encrypt-mac is more

Admittedly, I know very few encryption APIs.  The two that I know
offer CBC with both, a function that does PKCS-padding for you,
and one that does not perform padding.
PKCS#11 v2.01 (1997) seems to have both.

There are some applications that use padding other than PKCS-padding.
XMLenc is one example (PKCS-padding is a subset of valid XML-paddings).

> so, then a padding oracle is still possible.

Nope.  when using pad-mac-encrypt, then the mac will always be at the end,
and covered by the MAC computation.

-Martin

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Fri, 29 Nov 2013 23:38:58 +0200

> On 29.11.2013, at 22.17, [email-masked] (Martin Rex) wrote:
> 

I'm trying to explain my reasoning. First of all HMACs are designed to authenticate data safely, but encrypting them adds an unknown factor to the calculation. Why not just use them as they are supposed to be used.

For me it is much more intuitive to do pad-encrypt-mac compared to attack resistant pad-mac-encrypt. In current TLS spec you can give the plaintext+HMAC to the encryptor as is and let it handle the padding. The same is true for encrypt-then-mac, just give the plaintext to the encryptor (either CBC or stream) and let it handle the padding. But in pad-mac-encrypt you have to know the length of the MAC before you actually calculate the MAC and add it manually! This is counter intuitive.

Finally, encrypt-then-mac allows detection of tampering in an earlier stage, which is a plus in my books.

> rather than just a single one for all that fixes all known problems.

Ok, this is a valid point I have missed in the discussion. TLSv1.1 is a very small update to TLSv1, so one could always ask why is it not supported better. Is the version number change somehow scary to people?

That being said, I would support adding explicit IV to the encrypt-then-mac spec, unless we have reason to think it would slow down adoption. Personally I don't see how a block of random numbers would be too difficult.

Nikos, do you think you should combine the pad and the IV in the defined structs? It would fix the BEAST attack at the same time even in SSLv3...

> encrypted MAC provides a better safety margin than a plaintext MAC.

I don't think GHASH behaviour proves anything about HMACs, but please prove me wrong.

> for the GenericBlockCipher PDU.

But in a VERY hypothetical case where attacks to some HMAC is found, we would have no idea how it affects TLS without further analysis, using it in a standard way would at least give more information about what is broken. And of course HMAC is not just a hash.

> for patches/maintenance to the installed base.

I kind of find this comment contradicting with the "we should fix all known issues (BEAST) in a single patch" comment. But I admit SCSVs are a necessary evil because of compatibility issues. It just makes me feel dirty...

> than new products.  In particular,

Actually I wasn't talking about GCM which, as you say, is quite large.

> modes of encryption and somewhat of a contradiction to each other.

I was thinking something like http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-02 . It defines an AEAD CBC+HMAC mode which fixes all the known issues at once, as you suggested, but I find the padding outside of AEAD a bit of a hack. It is necessary only because we need to know the plaintext length in TLS AEAD interface _before_ decryption.

But getting people to accept an AEAD patch (just because it sounds scary if nothing else) is probably hard. I can understand why the chairs would like to go this "cleaner" route to fix CBC though.

Juho

---

From: [email-masked] (Martin Rex)
Date: Sat, 30 Nov 2013 00:07:49 +0100 (CET)

Juho Vähä-Herttua wrote:
> 
> [email-masked] (Martin Rex) wrote:
> > 
> I'm trying to explain my reasoning.  First of all HMACs are designed
> to authenticate data safely, but encrypting them adds an unknown
> factor to the calculation.  Why not just use them as they are
> supposed to be used.

There is nothing "unknown" about encryption, and certainly it will not
dillute the MAC (unless you come up with a bogus encryption scheme that
is not bijective--i.e. expands the data during encryption.

Keep in mind that encrypted MAC is what SSL&TLS have always been doing,
and what a number of implementations will continue to be doing for many
years to come.

If this had been the other way round, i.e. SSLv3 and TLS had been using
encrypt-then-mac, then I would not be asking to change it _unless_
a _real_ problem was demonstrated, and for the very same reasons
(don't fix it if it ain't broken, smaller code changes are more likely
to get adopted during maintenance).

> 
> For me it is much more intuitive to do pad-encrypt-mac compared to attack
> resistant pad-mac-encrypt. In current TLS spec you can give the
> plaintext+HMAC to the encryptor as is and let it handle the padding.

In current TLS, you pass the plaintext to the record layer, and the
record layer will pipe it thorugh the compression function and
pass it to the pad+mac+encrypt function.

>
> The same is true for encrypt-then-mac, just give the plaintext to the
> encryptor (either CBC or stream) and let it handle the padding.
> But in pad-mac-encrypt you have to know the length of the MAC before
> you actually calculate the MAC and add it manually! This is counter
> intuitive.

Actually, in TLS you have to _know_ the size of the MAC long before you
process the first record, because it is part of the Connection state:

  http://tools.ietf.org/html/rfc2246#section-6.1

   MAC algorithm
       An algorithm to be used for message authentication. This
       specification includes the size of the hash which is returned by
       the MAC algorithm.

Since compression algorithms other than the null compression will
usually have an output size different from the plaintext input size,
the size of the mac and the exact amount of padding is something
internal to the TLS record layer.  The caller above the record
layer doesn't need to know and doesn't need to care.

> stage, which is a plus in my books.

This is entirely irrelevant in the real world (for TLS).
You have to successfully go through a full TLS handshake before you can
mess around here, and the public key stuff during the full handshake
is so much harder on the honest server, that this is a lame argument.

> but please prove me wrong.

It does.  Why do you think that HMAC is better than a simple keyed hash?
because it doesn't make the output of the keyed hash directly accessible
to the attacker.  This immediately transcends from the definition of HMAC,

  http://tools.ietf.org/html/rfc2104#section-2

  H(K XOR opad, H(K XOR ipad, text))

and the rationale behind HMAC:

  http://tools.ietf.org/html/rfc2104#section-6

   6. Security

   The security of the message authentication mechanism presented here
   depends on cryptographic properties of the hash function H: the
   resistance to collision finding (limited to the case where the
   initial value is secret and random, and where the output of the
   function is not explicitly available to the attacker)

The "output of the function that is not explicitly available to the attacker"
is the output of the inner Hash function of the HMAC function.

It has the exact same output size as the output of the outer hash function.
Under given the assumption that H is "collision resistant", the outer
Hash-function of HMAC is equivalent to a symmetric encryption of
a block cipher with the blocksize of the hash size and the key "K".

Encrypting this the HMAC output again with a symmetric block cipher
is not going to weaken the resulting strength, but may strengthen it
when the properties of H are not as good as one might like.

> But in a VERY hypothetical case where attacks to some HMAC is found,
> we would have no idea how it affects TLS without further analysis,
> using it in a standard way would at least give more information about
> what is broken. And of course HMAC is not just a hash.

The security of HMAC is vitally dependent on the security of the underlying
hash function.

IIRC, The first weakness demonstrated for MD5 (by Dobbertin) were
modifications of two bits that cancelled each other out for a
specific internal state of the MD5 hash.  Later, methods were discovered
to compute two plaintexts that will have the same hash result for
arbitrary internal state.

What would be devastating for pad-encrypt-hmac is when a method was found
to find bit modifications that cancel each other out with little or no
dependence on the internal state of the hash.  This would immediately
and seriously affect all pad-encrypt-hmac schemes with that hash, the AEAD
and GenericStreamCipher schemes independent of encrypt-mac or mac-encrypt.

GenericBlockCipher with pad-mac-encrypt will be significantly less
impacted, because flipping specific bits on the plaintext (the data
that is mac'ed in pad-mac-encrypt) will only be possible if the
BlockCipher is broken as well.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 30 Nov 2013 00:22:38 +0100

On Fri, 2013-11-29 at 23:38 +0200, Juho Vähä-Herttua wrote:

> > I also dislike (a) making a change to SSLv3/TLSv1.0
> GenericBlockCipher > processing, but (b) leaving the predictable IV
> exploited by BEAST > unfixed, and essentially creating two seperate new
> GenericBlockCipher PDUs, > rather than just a single one for all that
> fixes all known problems.
> 
> Ok, this is a valid point I have missed in the discussion. TLSv1.1 is a
> very small update to TLSv1, so one could always ask why is it not
> supported better. Is the version number change somehow scary to people?

At the time of TLS 1.1, it was not known that a big number of TLS
implementations were not able to properly do TLS version negotiation and
handle gracefully a TLS version downgrade. In gnutls after we added TLS
1.1 we realized that enabling it would make the library unable to talk
to several (prominent at the time) servers. So I presume that this
compatibility issue and the fact that there was no popular demand (which
occurred only after the media hype with the beast attack), very few
bothered to implement it.

> That being said, I would support adding explicit IV to the
> encrypt-then-mac spec, unless we have reason to think it would slow
> down adoption. Personally I don't see how a block of random numbers
> would be too difficult.
> 
> Nikos, do you think you should combine the pad and the IV in the
> defined structs? It would fix the BEAST attack at the same time even in
> SSLv3...

Certainly the draft (or any other fix) could require that the TLS 1.1
explicit IV in CBC ciphersuites is used when used with TLS 1.0 or
earlier (although, that would make the protocol messier, it looks it
provides quite some advantages).

> > close to perfect.  We know painfully well that our hash algorithms >
> are *not* perfect, so I'm against taking chances, in particular > for
> the GenericBlockCipher PDU.
> But in a VERY hypothetical case where attacks to some HMAC is found, we
> would have no idea how it affects TLS without further analysis, using
> it in a standard way would at least give more information about what is
> broken. And of course HMAC is not just a hash.

Contrary to popular opinion on this list AtE is a standard way of
operation with no flaws known unless used with an unauthenticated pad
(as in TLS). When SSL 3.0 was designed AtE was believed to be the
conservative approach comparing to EtA.

regards,
Nikos

---

From: Watson Ladd <[email-masked]>
Date: Fri, 29 Nov 2013 17:23:02 -0800

>> defined structs? It would fix the BEAST attack at the same time even in
1/n-1 record splitting needs to be implemented anyway, thanks to the
installed base.
> conservative approach comparing to EtA.
The passive voice is doing a lot of work here. Bellare and Namparah
showed that EtA is generically secure,
AtE isn't. Rogaway sent out an email in 1995 pleading for EtA in TLS.
"no flaws known"!="proved to be secure"
AtE works only if the encryption and decryption functions are
bijective, as in stream cipher mode. Otherwise you have
an oracle. For CBC you restrict the message space to messages
multiples of the blocksize. But really, this is quibbling about
the color of a fence, rather than building it. Marsh Ray already
addressed these issues to the point where only the most blockheaded
would refuse to listen.

Furthermore, proliferating a mess of extensions and half-assed fixes
makes driving adoption of updates even harder.
The right to proceed is to provide something like a one round
protocol, that is secure, with no options, and sell adoption
on the new features. By making improved security contingent on TLS 1.2
adoption, we screwed ourselves over. But if what
results in a frankenprotocol on top of SSL 3.0, it might be better to
include a IM_OUTTA_HERE cipher which instructs the
recipient to do something sane instead.

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.
Sincerely,
Watson Ladd

---

From: [email-masked] (Martin Rex)
Date: Sat, 30 Nov 2013 02:44:49 +0100 (CET)

> 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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 30 Nov 2013 16:50:00 +0100

> "no flaws known"!="proved to be secure"

Proven to be secure doesn't mean that attacks don't exist. The TLS
padding scheme was proven to be secure prior to be broken; ironically by
the same person who made the proof. Attacks work by playing outside the
requirements of the proof.

Nevertheless, there is much more recent work on EtA vs AtE, that
actually proves AtE secure (not "generically" as you pose, you just need
a decent cipher). You may check "The order of encryption and
authentication for protecting communications (or: How secure is SSL?)".
There are even newer papers than that, it is just this that came to
mind.

regards,
Nikos

---

From: Alfredo Pironti <[email-masked]>
Date: Sat, 30 Nov 2013 18:25:12 +0100

> (which can be implemented as a random confounder) to all versions of TLS.

Please don't!
I think [1] does just what you're asking for. With 2 differences we
can agree upon:
1) Adding explicit IVs everywhere is a nice idea, and I'm up to add it
to the I-D.
2) If the paragraphs on non-GenericBlockCiphers really annoy you, just
ignore them.
To get a compliant implementation with non-block ciphers, all you have to do
is to add a 2-bytes empty vector to user data when sending, and parsing it when
receiving. All TLS implementations have a function for this, and it's
then a 2-lines patch.

> to how signaling is done for rfc5746 (TLS renegotiation_info extension).

I disagree with this. The more we add SSL3-compatible hacks, the more excuses
we give to vendors and to this WG to keep using SSL3.

[1] http://tools.ietf.org/search/draft-mavrogiannopoulos-new-tls-padding-01

Alfredo

---

From: "Paterson, Kenny" <[email-masked]>
Date: Sat, 30 Nov 2013 17:29:17 +0000

Hi Nikos, all,

I've been following this discussion with great interest, but keeping
rather quiet since my last contribution because I've been a bit busy with
other work, and because I was told that I was contorting reality last time
I tried to make a contribution...which left me somewhat disenchanted with
the tenor of the debate.

>requirements of the proof.

I assume here that you're referring to my "Tag size matters" paper with
Ristenpart and Shrimpton, and then to the Lucky 13 paper here. OK, with
some of my TLS credentials established for those who don't know me, here
are the key points that I take away from the TLS proof (from that paper)
versus the Lucky 13 attack:

The proof for MAC-then-Pad-then-Encrypt in TLS was extremely delicate and
difficult to produce. Indeed, in generating it, we came up with another
new attack on "TLS with short MACs" that excludes certain parameters from
ever being secure. We then had to make an assumption for the proof to go
through: that the decryption process does not leak the source of
decryption failure (sanity check failure, bad pad, or bad MAC), or any of
the timing involved in decryption.

What the Lucky 13 attack showed is that achieving this "uniformity of
errors" is very difficult for TLS's MAC-then-Pad-then-Encrypt construction.

And this is why MAC-then-Encrypt - and its real world variants - are being
given such a hard time on this list by some, including me: our bitter
experience is that implementing it securely is just much too hard. Witness
Adam Langley's 500 line patch for OpenSSL and NSS to get this (finally)
right. (Side note - Adam deserves credit for independently discovering the
same attack vector that we used in Lucky 13.)

To add a bit more detail: during the Lucky 13 disclosure process, I worked
with many vendors to help them get their patches ready. Very few of them
were actually able to completely eliminate timing side channels completely
in their implementations, and all that I know of (except for Adam) settled
for a "good enough" approach. Of course, that pragmatic approach is quite
justifiable. But it may still leave open small windows of opportunity for
future attack.

Bottom line: none of the many issues that MAC-then-Pad-then-Encrypt has
had in TLS should *ever* arise for Encrypt-then-MAC, unless the
implementer was extremely ill-educated.

To me, the perceived dangers of exposing the MAC - dangers which neither I
(nor any serious cryptographer I know) accept as being real - are far
outweighed by the simplicity and robustness provided by an
Encrypt-then-MAC approach.

>There are even newer papers than that, it is just this that came to

This is too simplistic an interpretation of that paper by Hugo Krawczyk,
I'm afraid. It's an excellent piece of work, and quite ahead of its time
in trying to apply provable security techniques to a real protocol. But it
has two major shortcomings if you try to apply it to CBC-mode encryption
as used in TLS:

1. It does not consider TLS padding whatsoever - but instead assumes data
is all block-aligned. As soon as you introduce padding in-between the MAC
and the encryption, i.e. as in TLS's actual construction, you run into
lots of trouble - Vaudenay, Bodo Moeller's observations, Lucky 13 and all.

2. It assumes the MAC output size is the same as the block cipher's block
size. Out of all mainstream TLS ciphersuites that I know, this is true
only for HMAC-MD5 with AES. And I think we all agree we'd like to avoid
MD5 now!

On the plus side, and perhaps this is what you were referring to, Hugo's
analysis works just fine for stream-cipher based ciphersuites (as long as
the stream cipher is good - so not RC4 then!). The Asiacrypt 2011 paper
can be seen as extending his analysis to handle the actual construction
used in TLS's CBC-mode ciphersuites, but with the important, necessary,
and difficult-to-achieve proviso concerning uniformity of errors.

Also on the plus side, Hugo's analysis can be fairly easily extended to
cover the Pad-then-MAC-then-Encrypt construction for CBC-mode encryption
that you, and others, have been arguing for (still under the assumption
concerning the size of the MAC tags and the block size, though it might be
that this assumption can be removed with more work). So there is indeed
theoretical support for this kind of construction. And maybe it can even
be implemented securely, too.

But, at the risk of repeating myself, I very much prefer the simplicity
and robustness of an Encrypt-then-MAC construction.

Of course, this is just another opinion, like many others that have been
expressed on this list recently, and I cannot hope it will be the last
word on the subject. But I can hope that it's accepted as an opinion born
from significant experience in analysing TLS security, from a variety of
perspectives (theoretical, implementation, attacks).

Best wishes,

Kenny

---

From: Alfredo Pironti <[email-masked]>
Date: Sat, 30 Nov 2013 18:58:30 +0100

Hi Kenny,

> and robustness of an Encrypt-then-MAC construction.

I agree with you. Indeed, Encrypt-then-MAC and (or within) AEAD are
the only two cipher modes I'd like to see in TLS 1.3.

In practice however, we witness the disastrous experience in widely
deploying any change which is not a small patch to TLS1.0. So I'm
afraid that to get something deployed in reasonable times we may have
to get content with such a patch, like pad-MAC-Encrypt, that makes
more robust (if not provably secure) what we already have.

Alfredo

---

From: Watson Ladd <[email-masked]>
Date: Sat, 30 Nov 2013 10:02:36 -0800

> the only two cipher modes I'd like to see in TLS 1.3.
You do realize EtM is an AEAD if properly designed?
> more robust (if not provably secure) what we already have.
How is pad-MAC-Encrypt less of a change then Encrypt then MAC?
We still can't kill RC4, which is a *configuration change*.
Patches aren't getting deployed even if painless, so arguing about the
ease of deployment is a red herring.

---

From: Alfredo Pironti <[email-masked]>
Date: Sat, 30 Nov 2013 19:23:53 +0100

> You do realize EtM is an AEAD if properly designed?

I do. I was just speaking in TLS1.2 terminology, which does make a
distinction, even though all schemes are supposed to deliver
Authenticated Encryption with Additional Data anyway. If I just said
that I only wanted AEAD, somebody else would have shoot at me instead
by saying that GCM is too inefficient.

> How is pad-MAC-Encrypt less of a change then Encrypt then MAC?

It is easier enough in that 2 implementations already implement pad-MtE
(GnuTLS and miTLS), and my personal experience in implementing the
patch says it's a small change.

But we need even more factual feedback, and I hope we get more people
to try to implement it elsewhere.