Re: [TLS] TLS1.3

[[e-mail] (Martin Rex)]

Peter Gutmann wrote:
> Martin Rex <[e-mail]> 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.

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.


> 
> >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.

Correct. 


> 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.


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