Re: [TLS] Spec tls13 comments, handshake tampering, mitigation, counter/seq_no predictability: WAS: Do we need DH?

[Michael Clark <[e-mail]>]

>  tls_record_protection_algorithm, length=11
>    tls_aead_aead_null, tls_ssf56,  aes_gcm, 128, hmac_null,
>    tls_aead_aead_null, tls_ssf56,  aes_ccm, 128, hmac_null,
>    tls_aead_aead_null, tls_ssf56,  camellia_gcm, 128, hmac_null,
>    tls_aead_aead_null, tls_ssf112, aes_gcm, 256, hmac_null,
>    tls_aead_aead_null, tls_ssf112, aes_ccm, 256, hmac_null,
>    tls_aead_aead_null, tls_ssf112, camellia_gcm, 256, hmac_null,
>    tls_aead_aead_null, tls_ssf112, chacha20_poly1305, 256, hmac_null,
>    tls_aead_aead_etm, tls_ssf168, aes_gcm, 256, hmac_sha2_256,
>    tls_aead_aead_etm, tls_ssf168, aes_ccm, 256, hmac_sha2_256,
>    tls_aead_aead_etm, tls_ssf168, camellia_gcm, 256, hmac_sha2_256,
>    tls_aead_aead_etm, tls_ssf168, chacha20_poly1305, 256, hmac_sha2_256,

These ciphers are essentially the four AEAD ciphers that have existing
IETF RFCs or drafts. CCM is a valid AEAD cipher choice and fits within
the draft framework.

However my earlier comment was that EAX (a NIST candidate) has
complementary properties and a security proof. EAX2, the foundation for
AES_EAX provides a generalized framework for Encypt-then-MAC i.e.
EAX2[AES,OMAC2[AES]]

I'm not attached to any of the ciphers and don't have an interest in
CCM, other than having a choice of 3 AEAD ciphers, and one of them from
NTT would be good. My conclusion on reading the literature was that EAX
has better properties than CCM, despite its slightly longer key setup
time (less then GCM) and equivalent performance to CCM. CCM is more like
CBC mode with MAC whereas EAX is more like CTR mode (GCM) with IV
increased entropy in the counter and the use of an alternative cipher
based MAC, making it complementary to the current suite.

AES_EAX has similar design properties to chacha20_poly1305 (poly1305
being a cipher based MAC based on AES security proof). This would be my
revised list removing CCM and including the NTT alternative and
chacha20_poly1305, both having IETF drafts (and losing interest in EAX):

tls_record_protection_algorithm, length=8
  tls_aead_aead_null, tls_ssf56,  aes_gcm, 128, hmac_null,
  tls_aead_aead_null, tls_ssf56,  camellia_gcm, 128, hmac_null,
  tls_aead_aead_null, tls_ssf112, aes_gcm, 256, hmac_null,
  tls_aead_aead_null, tls_ssf112, camellia_gcm, 256, hmac_null,
  tls_aead_aead_null, tls_ssf112, chacha20_poly1305, 256, hmac_null,
  tls_aead_aead_etm, tls_ssf168,  aes_gcm, 256, hmac_sha2_256,
  tls_aead_aead_etm, tls_ssf168,  camellia_gcm, 256, hmac_sha2_256,
  tls_aead_aead_etm, tls_ssf168,  chacha20_poly1305, 256, hmac_sha2_256,

1). if there are no AEAD ciphers with > 128-bit MACS, what is the
message forgery mitigation proposal for TLS application data?

2). is there consideration of an AEAD-ETM[null,hmac] for authentication
of handshake messages? i.e. handshake forgery mitigation proposal. The
random used for key derivation would need to be a constant AD on all
handshake messages to mitigate against handshake tampering. i.e.
authenticated handshake.

AEAD-ETM[aaed-cipher,hmac] would fall out of adding authentication to
the record protection layer and provide for extended authentication on
application data. These were my main concerns for draft-tls13.

The observation is that with the scope of global eCommerce, that
handshake tampering capabilities provide more harm than good. It pays
more to be merciful than mercenary when the core issue is protection of
public data (business and consumer). It is a farcical stance to deny
this protection if it is well known (as it is) that our eCommerce
handshakes can be tampered with by *any* ISP in any jurisdiction (with
or without the approval of various national affiliations).

Michael Clark
Independent.