Subject: [TLS] TLS1.3

From: "Lewis, Nick" <[email-masked]>
Date: Thu, 7 Feb 2013 08:43:11 +0000

With confidence in the TLS being undermined once again as a result of problems with its MAC-Pad-Encrypt mechanism are there any plans to adopt an alternative mechanism such as Pad-MAC-Encrypt in TLS1.3?

Nick Lewis
[email-masked]<mailto:[email-masked]>
+44 1684 277137<tel:+441684277137>
www.g4stechnology.com<http://www.g4stechnology.com/>
New Challenge House, International Drive, Tewkesbury, Gloucestershire, GL20 8UQ, UK

P Please consider the environment before printing this email

________________________________
The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

---

From: "Lewis, Nick" <[email-masked]>
Date: Thu, 7 Feb 2013 09:30:02 +0000

>I already have the necessary draft 90% complete, you don't need a rev of TLS,
>just an extension "would you like to do encrypt-then-MAC" in the client hello,
>and a corresponding "yes, let's do encrypt-then-MAC" in the server hello.
>Works with any version of TLS.  I'll post it in the next day or two.
>Peter.

Is this really ok for all cipher suites?
In those cases that the hash is weak e.g. MD5-HMAC maybe the underlying key could be exposed?
Padding the plain text up to a multiple of the cipher block size (minus the hash size) ahead of doing the MAC is a more modest change that may be more widely applicable to existing cipher suites - with a "pad-then MAC" client hello

Nick

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 7 Feb 2013 10:47:21 +0100

On Thu, Feb 7, 2013 at 9:43 AM, Lewis, Nick <[email-masked]> wrote:
> With confidence in the TLS being undermined once again as a result of
> problems with its MAC-Pad-Encrypt mechanism are there any plans to adopt an
> alternative mechanism such as Pad-MAC-Encrypt in TLS1.3?

Indeed that would be useful. The current padding mechanism required
1-2 pages of code to solve the known issues and that may not even be
sufficient, and have yet another attack next year.

For that, in gnutls we have already implemented an extension to
include the pad into the MAC'd data and avoid any padding oracle
attacks. The extension defines a new padding mechanism for all
ciphersuites (with the purpose of length hiding - Alfredo may add more
information on that), that has the side effect of fixing the known TLS
padding issues.

The extension is described at:
http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Feb 2013 04:56:26 -0800

There's not really any need to do a TLS 1.3 for this. TLS 1.2 includes
support for AEAD ciphers, so all that would be needed is to define
an Enrypt-Then-Mac AEAD cipher and it will drop into TLS 1.2.

Best,
-Ekr

On Thu, Feb 7, 2013 at 1:47 AM, Nikos Mavrogiannopoulos <[email-masked]>wrote:

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

---

From: "Lewis, Nick" <[email-masked]>
Date: Thu, 7 Feb 2013 13:10:42 +0000

>an Enrypt-Then-Mac AEAD cipher and it will drop into TLS 1.2.

Is it possible to define TLS1.2 AEAD cipher suites for existing ciphers and MACs?
AEAD implies to me the use of the same key for both crypt and MAC. Can the TLS1.2 AEAD specification allow different keys for each.
I think many MACs such as the HMACs require a different key to the crypt because there is no proof that sharing the key with the crypt does not weaken it

Nick

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 7 Feb 2013 14:20:15 +0100

> an Enrypt-Then-Mac AEAD cipher and it will drop into TLS 1.2.

I understand there are many ways to solve that (*), and there quite
few ideas on the table already. What is needed however, is to agree on
solution to be adopted for all.

regards,
Nikos

(*). Nevertheless, I am a bit confused with what you propose. I fail
to see the relation of a solution for the CBC padding issue with a new
AEAD ciphersuite. Do you propose to deprecate CBC?

---

From: "Paterson, Kenny" <[email-masked]>
Date: Thu, 7 Feb 2013 14:05:13 +0000

Hi,

http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01

provides a specification that could be rather easily adapted to the case in hand.

Kenny

Best,
-Ekr

---

From: "Lewis, Nick" <[email-masked]>
Date: Thu, 7 Feb 2013 14:10:16 +0000

>>Padding the plain text up to a multiple of the cipher block size (minus
>>the hash size) ahead of doing the MAC is a more modest change that may
>>be more widely applicable to existing cipher suites - with a "pad-then
>>MAC" client hello

>That won't help against the current attack.

My understanding is that the current attack is due to the MAC revealing the length of the plaintext.
If the plaintext is pre-padded to a full crypt block then a MAC can reveal no more than does the ciphertext itself

Nick

---

From: "Lewis, Nick" <[email-masked]>
Date: Thu, 7 Feb 2013 14:19:55 +0000

>provides a specification that could be rather easily adapted to the case in hand.

I like the way it overcomes the unproven security of using the same key for aes-cbc and hmac by simply concatenating two keys into the one supported by TLS1.2 AEAD

Nick

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Feb 2013 06:29:32 -0800

Yes, this is basically what I had in mind

-Ekr

On Thu, Feb 7, 2013 at 6:05 AM, Paterson, Kenny
<[email-masked]>wrote:

>  Hi,****
>
> ** **
>
> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01****
>
> ** **
>
> provides a specification that could be rather easily adapted to the case
> in hand.****
>
> ** **
>
> Kenny****
>
> ** **
>
> There's not really any need to do a TLS 1.3 for this. TLS 1.2 includes****
>
> support for AEAD ciphers, so all that would be needed is to define****
>
> an Enrypt-Then-Mac AEAD cipher and it will drop into TLS 1.2.****
>
> ** **
>
> Best,****
>
> -Ekr****
>

---

From: "Lewis, Nick" <[email-masked]>
Date: Thu, 7 Feb 2013 15:00:32 +0000

>Yes, this is basically what I had in mind

+1
It moves the responsibility for ensuring the security of the mechanism for combining padding, MACing and crypting from TLS to the individual cipher suites. This conveniently sidesteps the poor way it is done in TLS but also makes it easier to disable any other mechanisms that are found to be poor in the future (such as MAC-then-Crypt if it is ever found that SHA256 has Krawczyk weakness) . All useful cipher suites could be ported across to this way of working.

My only slight concern is the use of the term AEAD for this which implies the use of the same key for MAC and crypt. From a TLS perspective it may look like AEAD but the ported cipher suites themselves need to take care not to use a single key inappropriately

Nick

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 7 Feb 2013 09:19:40 -0800 (PST)

On Thu, February 7, 2013 7:00 am, Lewis, Nick wrote:
> My only slight concern is the use of the term AEAD for this which implies
> the use of the same key for MAC and crypt. From a TLS perspective it may
> look like AEAD but the ported cipher suites themselves need to take care
> not to use a single key inappropriately

  RFC 5116 defines a uniform interface for cipher modes that use the term
AEAD and RFC 5297 is an AEAD scheme that takes a double-wide key (half
for cipher, half for mac) and fits into the uniform interface (with the
assigned
numbers 15, 16, and 17). Your concern is misplaced; we're already doing
this.

  Dan.

---

From: "Lewis, Nick" <[email-masked]>
Date: Fri, 8 Feb 2013 09:35:24 +0000

>RFC 5116 defines a uniform interface for cipher modes that use the term AEAD
>and RFC 5297 is an AEAD scheme that takes a double-wide key (half for cipher, half for mac)
>and fits into the uniform interface (with the assigned numbers 15, 16, and 17).
>Your concern is misplaced; we're already doing this.

>Dan.

Thanks - seeing another example of concatenated keys helps to allay my fears (though ironically RFC5297 seems to specify a variant of CCM that may be secure with the same key for crypt and mac)
Nick

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Fri, 8 Feb 2013 12:22:18 +0000

+1

If there is a need for TLS to adopt an authenticated encryption method that uses AES-CBC and HMAC, then draft is already written, as Kenny points out.    It is also fairly mature and stable, and has seen a good amount of review.  There are four implementations that I've heard of so far, and a set of test cases thanks to John Foley and James Manger, which will be added in the update to the draft.

David

From: <Paterson>, Kenny <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 7, 2013 9:05 AM
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>, Nikos Mavrogiannopoulos <[email-masked]<mailto:[email-masked]>>
Cc: "Lewis, Nick" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] TLS1.3

Hi,

Kenny

Best,
-Ekr