Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis

From: Peter Gutmann <[email-masked]>
Date: Tue, 6 Jan 2015 10:27:04 +0000

Michael Clark <[email-masked]> writes:

>Before I've read through can we do this with it?
>
>AES-256-GCM + hmac_null   = 128 bits authentication
>AES-256-CBC + hmac_sha128 = 128 bits authentication
>
>AES-256-GCM + hmac_sha128 = 256 bits authentication
>AES-256-CBC + hmac_sha256 = 256 bits authentication
>
>AES-256-GCM + hmac_sha256 = 384 bits authentication
>AES-256-CBC + hmac_sha384 = 384 bits authentication

The MAC is whatever is negotiated for the session, and if you want a shorter
one you can send the truncated-MAC extension (which, however, nothing supports
AFAIK).  Having said that, see my previous message about not needing a
thousand options, we only need one that everyone uses.

Peter.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 6 Jan 2015 10:35:16 +0000

Hi

On 06/01/2015 10:27, "Peter Gutmann" <[email-masked]> wrote:

>AFAIK).  

It's good that nothing supports the truncated-MAC extension, because, in
combination with TLS's support for variable length padding, it introduces
a security vulnerability. See:

http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf

which shows that if the tag size (MAC length) is shorter than the CBC-mode
block size, then there's a distinguishing attack that can tell the
difference between the encryption of a short message and a longer message
(even though both are padded to the same size before encryption).

This is not an issue for any of the cihersuites proposed above, but it's
something to be kept in mind when considering "exotic" ciphersuites.

Regards

Kenny 

>Having said that, see my previous message about not needing a
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Tue, 13 Jan 2015 17:39:59 +0100

>> one you can send the truncated-MAC extension (which, however, nothing
For some definition of nothing, which includes CyaSSL, MatrixSSL, PolarSSL and
apparently RSA BSAFE too:
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Extensions

(FWIW, in PolarSSL we're going to disable it by default in the next major version.)

> (even though both are padded to the same size before encryption).
But if one does not expect any length hiding, is there still a problem with
truncated MACs?

Manuel.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 13 Jan 2015 17:52:41 +0000

Hi

>But if one does not expect any length hiding, is there still a problem

I think one would expect length hiding at least up to the granularity of
the block size in TLS with CBC mode. (The RFC even suggests that more
should be possible: "Lengths longer than necessary might be desirable to
frustrate attacks on a protocol that are based on analysis of the lengths
of exchanged messages." [1])

As a special case of the general attack, consider a notional application
using TLS that sends either the message "YES" or the message "NO". Suppose
we negotiate truncated MACs, and the TLS Record Protocol implementation
selects the amount of padding to add at random (from the set of possible
padding lengths allowed under the TLS padding scheme).

By truncating the ciphertext, doing some bit flipping, and reinjecting the
modified ciphertext, an adversary can tell whether "YES" or "NO" was
originally encrypted. (This assumes that the minimum amount of padding is
NOT selected; this happens with probability roughly 15/16 under the above
assumptions.) 

I'd consider that to be an attack in your "don't expect any length hiding"
setting - after all, the difference in plaintext lengths is just 1 byte,
which is well below the CBC-mode block size. Does that seem reasonable, or
is it still outside your attack model?

Cheers

Kenny

[1] RFC 5246, Section 6.2.3.2

---

From: Watson Ladd <[email-masked]>
Date: Tue, 13 Jan 2015 10:09:41 -0800

>From what I understand, when AES-GCM is used there isn't any padding,
and the length of the encrypted record is equal to the unencrypted one
plus the tag, so this attack still works. So if we accept this attack
(and I think we should), then the way AEAD ciphers are used in TLS are
also insecure. I believe this attack got used to determine autofill
entries in the Google search bar via passive observation, but I've not
dug up the paper, so my memory may be wrong.

To fix this we need to add padding in TLS 1.3 and TLS 1.2 for AEAD modes.

Sincerely,
Watson Ladd

---

From: Watson Ladd <[email-masked]>
Date: Tue, 13 Jan 2015 10:23:27 -0800

On Tue, Jan 13, 2015 at 10:15 AM, Paterson, Kenny
<[email-masked]> wrote:
> Hi Watson,
>
> On 13/01/2015 18:09, "Watson Ladd" <[email-masked]> wrote:
>
>>plus the tag,
> True.
>>so this attack still works.
>
> Actually, it's an even simpler, passive attack for AES-GCM - you just
> observe the ciphertext length and you are done. The attack on CBC mode
> requires an activity adversary and leads to closure of the TLS session
> half of the time.
>
>>So if we accept this attack
> That would be an interesting reference to have to hand. Please dig!

https://eprint.iacr.org/2014/959.pdf is the paper I was thinking of.

> https://tools.ietf.org/html/draft-pironti-tls-length-hiding-01 would be a
> good starting point, no?

Seem to be, although I don't remember it being discussed on the list
before. We should fix this problem.

-- 
"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: Tue, 13 Jan 2015 18:15:15 +0000

Hi Watson,

True.

Cheers

Kenny

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Jan 2015 10:32:26 -0800

> before. We should fix this problem.

We discussed it at some length at a meeting (Denver).  There was
significant interest in doing this, though I think we agreed that we
had to sort out a few things before the time was right.

See also https://github.com/tlswg/tls13-spec/issues/69

---

From: Michael Clark <[email-masked]>
Date: Wed, 14 Jan 2015 20:02:56 +0800

> See also https://github.com/tlswg/tls13-spec/issues/69

Interesting. Should draft-pironti-tls-length-hiding-01 be added to
Related Active Documents (not working group documents) section here:

    https://tools.ietf.org/wg/tls/

Michael

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Jan 2015 09:19:51 -0800

On 14 January 2015 at 04:02, Michael Clark <[email-masked]> wrote:
> Related Active Documents (not working group documents) section

That's an automatically generated list.  I suspect the reason that it
doesn't appear is that it is presently expired.

---

From: Tom Ritter <[email-masked]>
Date: Fri, 23 Jan 2015 19:26:56 -0600

> doesn't appear is that it is presently expired.

Something I feel very bad about. I am a big proponent of making length
hiding possible in 1.3 and need to find time to put more effort into this.
I encourage the chairs or WG to bug me if they don't see anything about
this in a timeframe they expect.

-tom

---

From: [email-masked] (Martin Rex)
Date: Sat, 24 Jan 2015 06:14:44 +0100 (CET)

Tom Ritter wrote:
> "Martin Thomson" <[email-masked]> wrote:
>>
>> Michael Clark <[email-masked]> wrote:
>>>

It would be easy to add length hiding (for all ciphers, STREAM, CBC, AEAD)
to all of TLSv1.x -- simply by defining a compression algorithm that
doesn't compress, but instead adds padding.  Compression algorithms
are allowed to inflate plaintext records up to a size of 2^14+1024 bytes.
And if that (anti-)compression algorithm would add random padding
on both ends of the plaintext, this could also frustrate attacks on
CBC padding and RC4 bias...

-Martin

---

From: Joe Hall <[email-masked]>
Date: Mon, 26 Jan 2015 13:46:49 -0500

On Fri, Jan 23, 2015 at 8:26 PM, Tom Ritter <[email-masked]> wrote:
> I encourage the chairs or WG to bug me if they don't see anything about this
> in a timeframe they expect.

Wasn't the discussion in Denver of the flavor that applications will
have to do length-hiding right if they want it to be secure so it
doesn't make sense to do it in TLS? I'm probably mischaracterizing
that, but I thought the outcome was more definitive than "maybe
someone will get to it". (i.e., some thought it would be a bad idea to
do it at all as it would be easy for applications to use it in an
insecure manner)

Apologies if this question is horribly naive. best, Joe

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Tom Ritter <[email-masked]>
Date: Mon, 26 Jan 2015 13:08:22 -0600

> do it at all as it would be easy for applications to use it in an

Length hiding in the application will be able provide more nuanced and
context-dependent protection, no doubt.  But that doesn't mean
providing it as a feature in the protocol is without merit.
Application-specific protection is more robust against adaptive query
attacks whether the adversary is measuring response time.  But for
response times visible in passive captures, an application is usually
not going to leak enough timing information for a reasonable guess on
a single query.  (Think an application taking more or less time to
process a small image versus a larger image - the "proper" way to do
this is inside the application, and have it adjust it's processing
time accordingly to not leak timing information.)

Length Hiding in TLS gets you good protection against passive captures
and lets you deploy the mechanism independent of building in the
feature at Layer 7 or above in multiple applications, application
protocols, web frameworks, etc.  (Some of which may be old and
unmaintained, but still running lots of services on the Internet.)

>From my recollection at Denver:
 - Consensus was we didn't want to pay a 2-byte penalty to put padding
in everywhere by default
 - Rough Consensus was padding without paying a penalty was something
reasonable to pursue
 - A few of us (dkg, myself, Alfonso) were going to think about how to
do that and also consider writing a BCP on why padding is useful, when
it makes sense, and rough strategies for doing it

-tom

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Jan 2015 11:18:16 -0800

> it makes sense, and rough strategies for doing it

That matches my recollection.  I think that it was deferred so that we
could pay more attention to the handshake.  I'm hoping that we can
start nailing down the macro-level handshake details in the next
couple of months, allowing us to get to this, content-type encryption,
removal of the version number from the record layer, and various other
interesting proposals that have been on hold.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 27 Jan 2015 09:33:37 +0100

> - Rough Consensus was padding without paying a penalty was something
 
If that refers to draft-pironti-tls-length-hiding-02, I believe these
comments are mislead. There is no penalty "everywhere" as you pose it.
Peers who need no padding don't use the additional length bytes. Only
peers who need to hide length use these two bytes. This is not a
penalty, as it can simply be considered part of the pad (min size of pad
= 2).

regards,
Nikos

---

From: Tom Ritter <[email-masked]>
Date: Tue, 27 Jan 2015 03:58:24 -0800

On 27 January 2015 at 00:33, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> If that refers to draft-pironti-tls-length-hiding0-2, I believe these

Yes, draft-pironti-tls-length-hiding-02 does not put a penalty
everywhere. One of the initial discussions was "Let's not make it an
option, let's just have padding by default, and the folks who don't
want to use it will put a zero-length pad".  But to do so, AIUI, we
needed to stash a 2 byte padding length somewhere. (Hence paying the
cost.) People didn't want to pay the extra two bytes all the time, so
we started looking at using an alternate record type (possibly
encrypting them), or an extension as in the draft...

-tom