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

From: Michael D'Errico <[email-masked]>
Date: Sun, 10 Nov 2013 12:28:51 -0800

In trying to figure out what's stalling the encrypt-then-mac draft
I came across this old message (below).  The complaint against the
draft appears to be that since the MAC is no longer encrypted, there
may be a way to recover the secret HMAC key.  HMAC-MD5 is mentioned
as the problem, so I checked to see which cipher suites use it.

The 13 cipher suites using MD5 are:

   A     0001    TLS_RSA_WITH_NULL_MD5
   B     0003    TLS_RSA_EXPORT_WITH_RC4_40_MD5
   C     0004    TLS_RSA_WITH_RC4_128_MD5
   D     0006    TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
   E     0017    TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
   F     0018    TLS_DH_anon_WITH_RC4_128_MD5
   G     0022    TLS_KRB5_WITH_DES_CBC_MD5
   H     0023    TLS_KRB5_WITH_3DES_EDE_CBC_MD5
   I     0024    TLS_KRB5_WITH_RC4_128_MD5
   J     0025    TLS_KRB5_WITH_IDEA_CBC_MD5
   K     0029    TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
   L     002A    TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
   M     002B    TLS_KRB5_EXPORT_WITH_RC4_40_MD5

Eight of these (A, B, D, E, G, K, L, and M) are considered trivially
breakable; F allows for a MitM; J uses the deprecated IDEA cipher;
and C and I use RC4 which we now know is completely broken.

That leaves only one cipher suite to possibly be concerned about:

   H     0023    TLS_KRB5_WITH_3DES_EDE_CBC_MD5

Do we really want to hold up the encrypt-then-mac draft any longer
because of this one Kerberos/triple-DES/MD5 cipher suite?

Mike

Nikos Mavrogiannopoulos wrote:
> On 09/08/2013 04:59 AM, Peter Saint-Andre wrote:
> 
>>> 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.
> 
> 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: Watson Ladd <[email-masked]>
Date: Sun, 10 Nov 2013 12:33:38 -0800

> as the problem, so I checked to see which cipher suites use it.
Who thinks this is a real problem? If the MAC is weak it shouldn't be used,
end of story. We have a real issue burning people now, and the
argument against it is
something that won't be an issue for a while, and only affects people
with their head in the
sand.
I say we publish it.
> because of this one Kerberos/triple-DES/MD5 cipher suite?
No.
> Mike
Sincerely,
Watson Ladd
> _______________________________________________
> 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: "Paterson, Kenny" <[email-masked]>
Date: Sun, 10 Nov 2013 20:39:36 +0000

Michael,

I posted on this back in September
(http://www.ietf.org/mail-archive/web/tls/current/msg09824.html). Let me
restate what I wrote then:

"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."

To summarise: the currently known attacks on MD5 do not have significant
consequences for the security of HMAC-MD5 in the TLS context.

So the issue you raise should not be holding things up.

Cheers

Kenny

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 10 Nov 2013 19:49:15 -0800

> So the issue you raise should not be holding things up.

Just to be clear, I didn't raise this issue.  It's the only
issue I came across that seems to be holding up the draft.

Mike

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 Nov 2013 00:33:49 +0100 (CET)

> as the problem, so I checked to see which cipher suites use it.

Personally, I would really prefer to _not_ move the MAC outside
of the encryption, i.e. leave it as pad-mac-encrypt like Serge Vaudenay
originally recommended.  In particular, keeping the hands off the
GenericStreamCipher PDU processing.

And in order to minimize the code changes and maximize the benefits,
I would use the same _fixed_ GenericBlockCipher PDU for all protocol
versions SSLv3->TLSv1.2 (i.e. including the random IV from TLSv1.1)
and with similar protection from downgrade attacks (for browsers doing
fallback reconnects) as rfc5746 renegotiation by defining another SCSV.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 12 Nov 2013 10:13:51 +0100

> GenericStreamCipher PDU processing.

I prefer this approach too, so I've taken the parts from the
length-hiding draft and moved them to a draft that simply describes a
new padding approach to solve the padding oracles. In any case I still
believe that something needs to be done about that, whether it is
pad-encrypt-then-mac or pad-mac-then-encrypt.

http://tools.ietf.org/html/draft-mavrogiannopoulos-new-tls-padding-00

regards,
Nikos

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 12 Nov 2013 09:53:40 +0000

Hi,

Is this preference based on security concerns or personal preference and
ease of implementation/adaption?

(Reading the Serge Vaudenary thread  suggest the latter - which is fine by
me - its worth considering the trade off.)

Encrypt-then-mac has some other security benefits. (Among others that the
decrypt routine never has
to process bogus/bad messages [e.g. those where the MAC would fail in
current encrypt-mac].).

regards,

ralf

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 Nov 2013 17:53:43 +0100 (CET)

> ease of implementation/adaption?

  - kiss principle (least amount of protocol and code changes)
  - don't fix if it ain't broken
  - conservative design, higher security margin.
  - personal preference

Stream & AEAD ciphers use XOR for encryption and neither supports random
padding, so manipulating known plaintext can be achieved with 100% precision.
I therefore want to ensure that my integrity protection has a very high
security margin.

> decrypt routine never has to process bogus/bad messages
> [e.g. those where the MAC would fail in current encrypt-mac].).

Which benefits are this?

I am not aware of any security benefit for the real world from
doing EtA over AtE.

If MAC erros were common in the wild, I would know about it,
because I would get customer inquiries about it and regularly see
it in error logs from customers.  During the last 10 years there was
only one occasion where a customer had a low, but persistent amount
of MAC errors.  On investigation, it wasn't MAC errors, it was
actually RSA decryption failures, caused by a firmware bug in
that customers SSL accellerator (for which the vendor produced
a firmware patch after we reported the problem).

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 Nov 2013 23:29:44 +0100 (CET)

Nikos Mavrogiannopoulos wrote:
> Martin Rex <[email-masked]> wrote:

This is a whole new extension adding bells and whistles, not a fix to
any existing issues, and appears to be heading for TLSv1.2-only.

Padding with arbitrary length is something that every application
could do with every TLS implementation already in the installed base
and every existing cipher suite, no changes to TLS necessary,
requiring only minor changes of the application protocol.

I would really like to see a _simple_ TLS extension that fixes the two
CBC issues for the GenericBlockCipher PDU for *ALL* versions of TLS
including SSLv3, making _all_ protocol versions use the same
GenericblockCipher PDU format again (the way this should have been
done in 2003).

You proposal adds the padding at the beginning only.  Since the
problem exhibited by RC4 is inherent to any XOR-encryption with
a pseudo-random-pad, AES-CCM, AES-GCM, etc. I would make such an
extension use random fraction, random content, authenticated padding
on both sides of the plaintext, with a combined minimum padding length of
at least 16 bytes, in order to mitigate statistical attacks on
any bias that may be found in the pseudo-random-pad.

But that is just an idea for what could be done if I had lots of free
time and nothing else important to do.

Seeing how slowly TLSv1.2(rfc5246) and TLS renegotiation extension (rfc5746)
are adopted by the installed base, I'm currently more interessted in
small changes and fixes to TLS that address real issues of the installed
base, such as interoperability problems (such as DHE parameter negotiation
and TLS protocol version intolerance and rsa premaster version goofs)
and weaknesses (published and unpublished).

-Martin

---

From: Ben Laurie <[email-masked]>
Date: Wed, 13 Nov 2013 12:35:54 +0000

On 12 November 2013 16:53, Martin Rex <[email-masked]> wrote:
> AEAD ciphers use XOR for encryption

Surely not by definition? It may be that the AEAD ciphers we use
currently use XOR, but we could create ones that don't, right?

---

From: "Bryan C. Geraghty" <[email-masked]>
Date: Wed, 13 Nov 2013 15:47:49 -0600

Martin Rex wrote:

>> Encrypt-then-mac has some other security benefits. (Among others that 
>> the decrypt routine never has to process bogus/bad messages [e.g. 
>> those where the MAC would fail in current encrypt-mac].).
> 
> Which benefits are this?
> 
> I am not aware of any security benefit for the real world from doing EtA
over AtE.

Look up "padding oracle attack". Lucky13 is a fairly recent example of a
real-world attack against AtE.
 
Bryan

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 14 Nov 2013 04:49:30 +0100

> requiring only minor changes of the application protocol.

There are two options. (a) Minor changes to the application protocol
(for all application protocols), or (b) minor changes to the TLS
protocol. The draft above takes the latter approach.

I also don't understand what do you mean by heading TLSv1.2-only. The
proposal in the above draft works from SSL 3.0 to TLS 1.2. There is
nothing TLS 1.2-specific there.

> any bias that may be found in the pseudo-random-pad.

The above draft does:
1. prevent padding oracle attacks
2. hide the length of the plaintext

What you propose there is having the plaintext appear and finish in an
unpredictable position. That's an interesting approach, not handled by
the draft above.

In simple terms you're asking for more bells and whistles :)

regards,
Nikos

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 13 Nov 2013 20:15:16 -0800

> In simple terms you're asking for more bells and whistles :)

If I recall correctly from DJB's paper, the problem with RC4 is bias in
the first 256 or so bytes of the key stream.  Would it be possible to
"fix" RC4 using this extension?  Simply insert a random amount (at
least 256 bytes) of pseudo-random padding at the beginning of the first
record sent using an RC4 cipher suite?

Mike

---

From: Watson Ladd <[email-masked]>
Date: Wed, 13 Nov 2013 20:48:34 -0800

> record sent using an RC4 cipher suite?
You recall incorrectly. The bias DJB et al. discovered was not the bias that
explains why RC4 should not be used: the Fluhrer-McGrew bias in all
bytes dooms RC4.

We have a perfectly good mode: AES-GCM. We should use it.
This whole topic is a waste of time: For a good stream cipher it does nothing,
for a bad stream cipher it also does nothing.

Let's talk about the real problems: slow deployment of TLS 1.2, Suite
B not being used extensively,
reducing round trips, lack of protection against downgrades, TCP shenanigans.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Thu, 14 Nov 2013 09:47:46 +0000

On 14/11/2013 04:15, "Michael D'Errico" <[email-masked]> wrote:

>the first 256 or so bytes of the key stream.

You recall incorrectly. Re-read sections 4.2, 5.2, 5.3.3 and 7 of the
paper:

http://www.isg.rhul.ac.uk/tls/RC4biases.pdf

>Would it be possible to

No.

Please read Section 7 of the paper. This idea, and variants of it, are
specifically addressed and dismissed.

Regards,

Kenny

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 14 Nov 2013 10:52:13 +0100

> record sent using an RC4 cipher suite?

Kenny answered on the question. However, even if it would solve it,
would it really be worth it to make hacks to save RC4?

regards,
Nikos

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 14 Nov 2013 10:10:47 +0000

Watson Ladd:
> Suite B not being used extensively,

As a side note, they call it Suite B for a reason, no?

I think that agl's plan of "ChaCha20 and Poly1305 for TLS" is much better:

  https://www.imperialviolet.org/2013/10/07/chacha20.html

All the best,
Jacob

---

From: [email-masked] (Martin Rex)
Date: Thu, 14 Nov 2013 16:05:31 +0100 (CET)

> real-world attack against AtE.

You're mistaken.

The "padding oracle attacks" against CBC, both originally described
by Serge Vaudenay, and the attack described by Hugo, are against
"authenticate-extend-encrypt" schemes one of which being the
"mac-pad-encrypt" used by TLS.

I was asking for security benefits of a EtA over a _real_ AtE scheme, and
I am not aware of any.

-Martin

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Thu, 14 Nov 2013 15:47:07 +0000

Hi Martin,

1. EtA discards a malicious packet earlier than AtE. This means the packet
is processed by less programm code and the attacker has less chance to
trigger a vulnerability in the program code (We are talking buffer overflow
[etc!] here as well and not just crypto-vulns).

2.With AtE there is a correlation between the MAC and the plaintext. This
turns any known-plaintext attack into a ciphertext only attack and you
should not have a correlation even if this correlation can not be exploited
today by public cryptanalytic means.

EtA is the conservative choice.

regards,

ralf

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 14 Nov 2013 17:00:18 +0100

> [etc!] here as well and not just crypto-vulns).

This is an often repeated argument. How many of these attacks are we
currently seeing in TLS that doesn't use EtA? None. The difference in
processing is really negligible to be used in a serious attack.

> today by public cryptanalytic means.

I don't understand your point. How would they work when the MAC is encrypted?

Both EtA and AtE have weak points, depending what you trust more, the
cipher or the MAC. With EtA you need to trust the MAC as any attacker
has access to the MAC and the actual authenticated data (which is the
ciphertext).

regards,
Nikos

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Thu, 14 Nov 2013 16:05:17 +0000

> has access to the MAC and the actual authenticated data (which is the
Program code:
With EtA you need to trust the MAC. With AtE you need to trust the cipher
_and_ the MAC.

Correlation with plaintext:
I do not understand your argument. With EtA there just is no correlation.
That's a good thing. Only with AtE there is (that's a bad thing).

regards,

ralf

regards,

---

From: [email-masked] (Martin Rex)
Date: Thu, 14 Nov 2013 17:07:41 +0100 (CET)

> [etc!] here as well and not just crypto-vulns).

This is completely irrelevant in the real world and for TLS specifically.
(it may be slightly different for DTLS).

> today by public cryptanalytic means.

This is just wrong.

With AtE, the MAC is encrypted as well, and in the case of TLS, it is
not a simple hash on the plaintext, but an HMAC with a secret integrity
protection key.  There is nothing you can learn from an encrypted HMAC.

For EtA this is different.  You have the MAC in plain, you have all
the data that is MACed (the ciphertext) in plain, the only remaining
unknown is the key for the HMAC.  If there is a weakness in the
MAC scheme, this is where it could be attacked, if at all.

> EtA is the conservative choice.

Nope, EtA is taking chances.

-Martin

---

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

> With EtA you need to trust the MAC. With AtE you need to trust the cipher

I believe you're confused.

The MAC provides integrity protection, the Encryption provides
confidentiality.  The quality of the MAC has exactly Zero impact
on the confidentiality provided by the Encryption.

For EtA, the characteristics&quality of the Cipher do not affect
(and therefore can not improve) the quality of the MAC scheme
at all.

For AtE, the characteristics&quality of the Cipher additionally
strengthen the quality of the MAC scheme, so weaknesses in the MAC
scheme do not immediately translate into a vulnerability.

Look at AES-GCM (NIST SP800-38D).  They use an efficient keyed has GHASH,
that does not have cryptographic hash properties (2nd paragraph Page 10):

  http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf

  GHASH is a keyed hash function but not, on its own, a cryptographic
  hash function. This Recommendation only approves GHASH for use within
  the context of GCM.

The use of GHASH without cryptographic protection would not be safe.

-Martin

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Thu, 14 Nov 2013 16:21:58 +0000

Hi,

yes, your point on 2. is valid and I agree with it. AtE gives less option
to attack HMAC.

I'm a bit more conservative on 1. OpenSSH used to have the same 'we do not
care, not a lot of code is executed before auth anyway' and they learned
the hard way (pre-auth remote overflows because to much code was executed
before auth that could have been executed post-auth).

Writing vulnerability free source is hard. OpenBSD tried hard and failed
(2002).

Looks like we have to balance between trusting HMAC vs. trusting that the
decrypt-code is vulnerability-free.

regards,

ralf

---

From: Alex Elsayed <[email-masked]>
Date: Thu, 14 Nov 2013 12:28:29 -0800

> The use of GHASH without cryptographic protection would not be safe.

I think what Ralf meant was "the *implementation* of the $foo" - there _is_ 
a reduction of attack surface by ensuring that only the MAC could be exposed 
to forged content; however I would also agree that if your TLS 
implementation is vulnerable to buffer overflows in the cipher you have 
bigger problems. Like that you used such a thing in the first place.

OTOH, there may be an argument regarding performance and denial-of-service - 
by using EtA, forged messages can only force the target to spend cycles on 
the MAC, while AtE would permit a greater load to be imposed.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Thu, 14 Nov 2013 23:24:02 +0000

>on the confidentiality provided by the Encryption.

Unfortunately, you're completely wrong. The MAC is also necessary to
preserve confidentiality in the face of active attacks. It's a very common
misunderstanding amongst novice cryptographers to believe that there's a
separation:

	MAC <-> integrity
	Enc <-> confidentiality

If you need an example, consider the security history of IPsec's
encryption-only modes. (Am I allowed to mention IPsec on a TLS list? Well,
I just did.) 

These modes provide confidentiality against passive attackers, yes, but
they fail pretty spectacularly against active attackers. Bellovin was the
first to show that; the nadir for encryption-only IPsec came in my 2007
Oakland paper with Jean Paul Degabriele, full version here:

http://eprint.iacr.org/2007/125

(Just read the abstract if you've forgotten the headline.)

And, as far as I know, there are no significant attacks when IPsec is
configured in encrypt-then-MAC configurations (e.g. ESP conf+auth or ESP
followed by AH). On the other hand, all the configurations of IPsec where
the MAC is applied before the encryption are broken. (Another
demonstration that MAC-then-encrypt is not a robust choice.)

>(and therefore can not improve) the quality of the MAC scheme

That's true but irrelevant, unless you don't trust your MAC algorithm. So
why do you not trust HMAC-SHA256? Can you point to any shred of evidence
that it is weak in some way? That it is likely to become weak? That its
extensive security analysis is wrong? Without back-up of this kind, your
argument is just hot air. See also Marsh Ray's recent post.

>scheme do not immediately translate into a vulnerability.

That's true too, but should be accorded small weight in the argument given
the litany of attacks against MAC-then-encrypt constructions.

>The use of GHASH without cryptographic protection would not be safe.

Also true. But guess what? In GCM, the GHASH MAC is computed on the
ciphertext! The GHASH output is then encrypted using a further invocation
of the block cipher. Where does this leave your argument in favour of
MAC-then-encrypt?

Kenny

---

From: [email-masked] (Martin Rex)
Date: Sat, 16 Nov 2013 00:11:24 +0100 (CET)

Paterson, Kenny wrote:
> 
> "Martin Rex" <[email-masked]> wrote:
> >
> The MAC is also necessary to preserve confidentiality in the face
> of active attacks.

That is a contortion of reality.  The MAC does not preserve anything
here.  The purpose of the MAC in communication protocols is to
mitigate the reaction/behaviour of the recipient of the communication
to become an oracle that can be polled quickly, repeatedly and often
to reveal fractions of bits of information that can be accumulated
by an attacker into disclosure of bytes of assumed confidential data.

> encryption-only modes. (Am I allowed to mention IPsec on a TLS list?
> Well, I just did.) 

The few things that I looked at were simple consequences of obviously
flawed assumptions, i.e. providing an oracle to the attacker and
no mechanism to stop an attacker from polling the oracle and learning.

Cryptographic algorithms have specific properties, and so do protocols
employing cryptographic algorithms.  Silently assuming that certain
properties will exist by accident/chance, rather than by explicit
design, is somewhat naive.  While it has been finally spelled
out in rfc5246 (TLSv1.2):

  http://tools.ietf.org/html/rfc5246#page-16

   Any protocol designed for use over TLS must be carefully designed to
   deal with all possible attacks against it.  As a practical matter,
   this means that the protocol designer must be aware of what security
   properties TLS does and does not provide and cannot safely rely on
   the latter.

a lot of consumers just don't get it.  They want to continue using
TLS as a magic pixie dust that provides universal security.

> demonstration that MAC-then-encrypt is not a robust choice.)

It is formally provable that MAC-then-encrypt for the existing symmetric
ciphers is at least as safe as encrypt-then-MAC.  The problem is, that
this applies only to _real_  MAC-then-encrypt, not to
any MAC-then-ExtendAndOtherStuff-then-Encrypt schemes that have
been used in IPsec and TLS, and are still being used in CMS|S/Mime
and WSSecurity, where additional unauthenticated data (e.g. padding)
is added after the MAC and before encryption, and where the recipient
will be offering a public decryption oracle.

> why do you not trust HMAC-SHA256?

This isn't about the best-case scenarios, but about worst case scenarios,
i.e. HMAC-MD5.  The GHASH of AES-GCM by itself is weaker than HMAC-MD5,
but by being encrypted, the attacker can not take advantage of this.
An encrypted MAC will never be weaker than a plaintext MAC, but a
plaintext MAC may be turn out to be a weakness/vulnerability.

> ciphertext!

The point is, that the AES-GCM MAC _is_ encrypted, and sending it
unencrypted would not be a good idea.

>
> The GHASH output is then encrypted using a further invocation

The MAC in TLS'es GenericBlockCipher ought to be left encrypted.
And to make code changes small, efficient and managable, going
from mac-pad-encrypt to pad-mac-encrypt, as Serge Vaudenay suggested,
is IMO the most reasonable way forward.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 19 Nov 2013 02:43:15 +0100 (CET)

> protocol. The draft above takes the latter approach.

Personally, I prefer to seperate true fixes
(such as changing mac-pad-encrypt -> pad-mac-encrypt) from
new features.

> nothing TLS 1.2-specific there.

The AES-CCM and AES-GCM specs take the extreme position that everything
that refers to GenericAEADCipher PDU must be TLSv1.2 exclusively.

I would very much welcome if we could kill this, and let implementors
use GenericAEADCipher with whatever TLS version they see fit.
Such a relaxation should be negotiated, though, to avoid confusion
(and interop problems) with excessively pedantic implementations
that follow obviously flawed suggestions in immature specifications.

> In simple terms you're asking for more bells and whistles :)

If you can't be good, at least be good at it.  :)

If you want to retrofit random padding into TLS (and into the stream and
aead cipher PDUs specifically), then you could at least try to mitigate
the most obvious problems with XOR-encryption schemes: the problems with
biases/patterns in the pseudo-random-pad and the possibility to accurately
flip individual bits in the plaintext.

-Martin

---

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

> http://tools.ietf.org/html/draft-mavrogiannopoulos-new-tls-padding-00
 
If you leave the fixing (and changing) of the Cipher PDUs alone,
you could alternatively pursue a "random padding" by simply defining
an (anti-)compression algorithm to that effect, with whatever semantics you
desire.  This might also fit smoother with implementations.

The hard limit that your fancy (anti-)compression algorithm will
have to observe from the TLS specs,
  e.g. http://tools.ietf.org/html/rfc5246#section-6.2.2

is that the output of your (anti-)compression must not exceed 2^14+1024
bytes.

The "may not increase the content length by more than 1024 bytes" rule
is more of a soft rule that can be adjusted by the (anti-)compression
algorithm spec as long as the "the output must not exceed 2^14+1024"
hard rule is obeyed.

-Martin

---

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

> algorithm spec as long as the "the output must not exceed 2^14+1024"

That's a pretty clever observation, and would be of quite use if the new
padding mechanism is not used. Note however, that one would want to keep
a uniform size in records and padding should be within the 2^14 limit
(or the max data limit); otherwise it may be of little use in hiding the
length.

regards,
Nikos