Re: [TLS] TLS1.3

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: <uri@ll.mit.edu>
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:pgut001@cs.auckland.ac.nz]
Sent: Saturday, February 09, 2013 09:51 PM
To: tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] TLS1.3

Martin Rex <mrex@sap.com> 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 :-).
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls