Re: [TLS] TLS1.3

[[e-mail] (Martin Rex)]

Peter Gutmann wrote:
> "Lewis, Nick" <[e-mail]> writes:
>> 
>>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.  The only proper fix for the
> various attacks that target the encryption is to protect everything with the
> MAC, i.e. switch to encrypt-then-MAC.  The definitive reference for this is
> Hugo Krawczyk's "The Order of Encryption and Authentication for Protecting
> Communications (Or: How Secure is SSL?)".

I disagree.  What you're saying is that the countermeasures that
are currently being adopted would not help against the current attack.


I do believe that pad, hash, encrypt would be sufficient (while still being
sensitive about ensuring the same codepath).


Looking at the original Paper from Sergey Vaudenay from 2001:

  http://infoscience.epfl.ch/record/52417/files/IC_TECH_REPORT_200150.pdf

  Section 5.1  SSL/TLS 2nd paragraph  (page 6):

  TLS v1.0 also provides an optional MAC which failed to thwart the attack:
  when the server ¯gures out that the MAC is wrong, it yields the bad_record_mac
  error. However, the message padding is performed after the MAC algorithm, so
  the MAC does not preclude our attack since it cannot be checked before the
  padding in the decryption.

explains that TLS has is susceptible to the timing attack due to
MAC-then-pad, and then describes in

  Section 6.5 CBC-PAD with Integrity Check

  One can propose to add a cryptographic checkable redundancy code
  (crypto-CRC) of the whole padded message (like a hashed value)
  in the plaintext and encrypt

                message|padding|h(message|padding)

  This way, any forged ciphertext will have a negligible probability
  to be accepted as a valid ciphertext. Basically, attackers are no
  longer able to forge valid cipher-texts, so the scheme is virtually
  resistant against chosen ciphertext attacks.

  Obviously it is important to pad before hashing: padding after
  hashing would lead to the a similar attack. The right enciphering
  sequence is thus

                pad, hash, encrypt

  Conversely, the right deciphering sequence consists of decrypting,
  checking the hashed value, then checking the padding value.
  Invalid hashed value must abort the decipherment.


Making the code use the same CPU cycles would definitely _much_ easier
with TLS doing pad-MAC-encrypt, then with the original MAC-pad-encrypt.

I'm actually slightly puzzled why this change was not made in TLSv1.1
along with backwards-incompatible change of the GenericBlockCipher PDU
that added an explicit IV.


-Martin