Subject: Re: [TLS] TLS1.3

From: Peter Gutmann <[email-masked]>
Date: Sun, 10 Feb 2013 02:51:31 +0000

Martin Rex <[email-masked]> writes:

>Personally, I also feel somewhat uncomfortable with a "radical" change to
>encrypt-then-MAC rather than the simply using the obvious pad-MAC-encrypt, as
>originally suggested by Serge Vaudenay.

It's hardly a radical change, in terms of code complexity (at least in my
code) it came down to (comments and error checking removed) this:

  checkMacTLS( sessionInfoPtr, data, length, length - sessionInfoPtr->authBlocksize, packetType );
  decryptData( sessionInfoPtr, data, length - sessionInfoPtr->authBlocksize, &length );

In other words I swapped two lines of code.

(See my earlier note about what it really entailed, which was creating a
separate code path that removed several hundred lines of kludging to try and
defend against side-channel attacks.  So really it's a two-line swap and
hundreds of lines removed, at least for the encrypt-then-MAC option).

>When the encryption scheme that is used is bijective, then it will not matter
>(to the confidentiality of the encryption) whether AtE or EtA is used, as
>long as authentication covers the exact same information in both cases, i.e.
>*ALL* of it, padding included.

However you do need to to MAC the IV.  If you treat it as part of the
ciphertext then it's trivial, MAC the entire packet in its bits-on-the-wire
form.  If you're MAC'ing the plaintext then you need to special-case the IV
vs. the plaintext and suddenly you're adding all sorts of kludgery to handle
that.  Authenticating the exact bits on the wire is both cleaner conceptually/
security-wise (you're authenticating the exact data that the attacker has
access to, not some bits as seen by the attacker and some bits as seen by you
after further processing), and implementation-wise (you just swap the bits of
code that do auth. vs. encrypt).  To quote Kenny Paterson's recent message:

  It fixes every problem I can conceive of.  And I've thought about the
  analysis of TLS's current MAC-pad-encrypt construction long and hard,
  believe me.

That's pretty unambiguous.

>However, in the EtA scheme, we would have a naked keyed hash.  And would an
>attack on the keyed hash become somehow feasible, that attack might be easier
>on a naked keyed hash than on an encrypted keyed hash.

That's going to be pretty unlikely, if someone can break HMAC then we've got
more serious things to worry about than forging of TLS packets.

Peter.

PS: Still keen to interop-test with anyone else who's made this change :-).

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Sat, 9 Feb 2013 22:12:58 -0500

I worry much less about attacks against "naked" keyed hash (such as HMAC, or in fact any other cryptographic MAC) than against attacks against encrypted padding, etc.

Pad->Encrypt->MAC is the most straightforward solution, IMHO, and I see no reason doing something else.

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <[email-masked]>
Lexington, MA  02420-9185       

Web:  http://www.ll.mit.edu/CST/

MIT LL Root CA: 

 <https://www.ll.mit.edu/labcertificateauthority.html>

DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Peter Gutmann [mailto:[email-masked]]
Sent: Saturday, February 09, 2013 09:51 PM
To: [email-masked] <[email-masked]>
Subject: Re: [TLS] TLS1.3

Peter.

PS: Still keen to interop-test with anyone else who's made this change :-).
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 Feb 2013 16:29:34 +0100 (CET)

> In other words I swapped two lines of code.

But this sounds like your changing the semantics for all ciphersuites,
including the GenericStreamCipher PDU, which includes ciphers
such as TLS_RSA_WITH_RC4_128_MD5, and AEAD ciphersuites.

Personally, I would prefer to limit this change to the processing
of the GenericBlockCipher PDU of TLS.

> However you do need to to MAC the IV.

Correct. 

> If you treat it as part of the ciphertext then it's trivial,
> MAC the entire packet in its bits-on-the-wire

I would really hate having to add a black-list of cipher suites that
must not be used with the new scheme (such as TLS_RSA_WITH_RC4_128_MD5)
in a few years, when it turns out that an HMAC-MD5 is too weak.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 Feb 2013 16:33:27 +0100 (CET)

> > However you do need to to MAC the IV.

Re-thinking it,  I believe it would be OK to _not_ cover the CBC-IV
in the AtE, while you *MUST* cover the IV in the EtA case.

The reason being that the IV does not impact the bijectivity of the cipher,
and is not part of the plaintext.

-Martin

---

From: Scott Schmit <[email-masked]>
Date: Fri, 15 Feb 2013 22:13:12 -0500

On Mon, Feb 11, 2013 at 04:33:27PM +0100, Martin Rex wrote:
> Martin Rex wrote:
> > > >When the encryption scheme that is used is bijective, then it
> > > >will not matter (to the confidentiality of the encryption)
> > > >whether AtE or EtA is used, as long as authentication covers the
> > > >exact same information in both cases, i.e.  *ALL* of it, padding
> > > >included.
> > > 
> Re-thinking it,  I believe it would be OK to _not_ cover the CBC-IV in
> the AtE, while you *MUST* cover the IV in the EtA case.

Look at the CBC decrypt operation again. If I can modify the IV, I can
modify the first block of your plaintext.  So much for authentication...

-- 
Scott Schmit

---

From: [email-masked] (Martin Rex)
Date: Sat, 16 Feb 2013 05:53:56 +0100 (CET)

> modify the first block of your plaintext.  So much for authentication...

I'm sorry, but I fail to see what your comment refers to.

The CBC-IV is either part of the ciphertext or part of the keying material,
but never part of the plaintext.

For Authenticate-then-Encrypt (AtE), it is unnecesary to cover the IV
by the Authentication (it is also not currently done in TLS), and
independent of whether the CBC-IV is part of the keying material
as in SSLv3/TLSv1.0 or part of the ciphertext as in TLSv1.1+.

For Encrypt-then-Authenticate, you MUST cover the CBC-IV by the
authentication when it is part of the ciphertext (TLSv1.1+), and
you MAY cover the CBC-IV (or not) when it is part of the keying
material (SSLv3/TLSv1.0)

-Martin

---

From: Scott Schmit <[email-masked]>
Date: Sat, 16 Feb 2013 00:09:05 -0500

> you MAY cover the CBC-IV (or not) when it is part of the keying

Ah, right.  I misread.  Sorry for the noise.

-- 
Scott Schmit