Re: [TLS] Inclusion of OCB mode in TLS 1.3

[Jack Lloyd <[e-mail]>]

On Fri, Jan 16, 2015 at 04:58:36PM +0100, Aaron Zauner wrote:
> Hi,
> 
> I came up with the following list of cipher-suites applicable to >= TLS 1.2:
> 
> (EC)DHE:
> TLS_DHE_RSA_WITH_AES_128_OCB	
> TLS_DHE_RSA_WITH_AES_256_OCB
> TLS_ECDHE_RSA_WITH_AES_128_OCB
> TLS_ECDHE_RSA_WITH_AES_256_OCB
> TLS_ECDHE_ECDSA_WITH_AES_128_OCB
> TLS_ECDHE_ECDSA_WITH_AES_256_OCB
> 
> PSK:
> TLS_DHE_PSK_WITH_AES_128_OCB
> TLS_DHE_PSK_WITH_AES_256_OCB	
> TLS_ECDHE_PSK_WITH_AES_128_OCB
> TLS_ECDHE_PSK_WITH_AES_256_OCB
> 
> As for the nonce, would it make sense to use a 128bit nonce for both
> AES128 and AES256 instead of 64/128 (see:
> https://www.imperialviolet.org/2014/05/25/strengthmatching.html)?

OCB mode as defined in RFC 7253 supports nonces of at most 120 bits.

When used in TLS both GCM and CCM use 96 bit nonces, 32 from key
exchange and 64 explicit in the message. Given the 2^64 message limit
(and that any sensible implementation just uses the sequence number
for the 64 nonce bits included in each message) I don't see why OCB
should require anything different. A 128 bit nonce isn't increasing
the security level when it is already 100% guaranteed that the nonce
will never repeat using just 96.

Another option would be to avoid explicit nonces entirely and
following ChaCha20 define the nonce to always be exactly the sequence
number in network order. This value is known to be unique for protocol
reasons, and it avoids the wire bytes taken for any explicit value.

Cheers,
  Jack