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

[Aaron Zauner <[e-mail]>]

Hi Stephen,

Stephen Farrell wrote:
> <no-hats>
> 
> On 13/01/15 18:25, Paul Lambert wrote:
>> This should not stop inclusion of OCB as an optional mode in TLS,
> 
> I don't get why additional options are at all attractive. In
> fact, I think they're ugly.
> 
> TLS has about 327 ciphersuites. That's just stupid. (I'm not
> saying any person is stupid there btw, but we have gotten
> ourselves into a stupid place.)

Yup. Having different naming schemes for different
libraries/implementations beyond that makes it almost impossible to give
good recommendations to end-users (admins, management) as we've noticed
in the bettercrypto.org project.

> 
> If we have a really better thing, they why not make it MTI? If
> we do not have something sufficiently better then I'd argue to
> exclude as much as possible, and certainly against adding
> anything that is just nice to have.
> 
> I'd even like to make almost all current ciphersuites a MUST NOT
> (or start a new registry) for TLS1.3 and to not add any new
> ciphersuites at all, and just stick with two MTI ciphersuites
> that are as genetically different as possible and cover as many
> implementations (h/w AES or not) as possible.
> 
> So my suggestion is to reduce the ciphersuite field to be
> 2 bits wide in TLS 1.3, with 00 being default, 01 backup, 02
> being "proprietary" and 03 reserved. If either 00 or 01 needs
> to be changed then I'd say rev the TLS version. (I don't care
> if we did s/default/has-AES-hw/ and s/backup/just-sw-crypto/
> that'd also be fine.)
> 
> And yes, I realise that's not likely to get traction, but
> turning 327 into 427 is even dumber when reality shows that
> only a few of 'em are used or needed.

Just as a suggestion, how about a document that does only include
forward-secret cipher-suites that are valid for TLS 1.3? That would
drastically remove the number of OCB ciphersuites that I would have to
add in case of TLS 1.2.

One issue though: as far as I can tell (from the recent RWC presentation
by EKR) there are still going to be three block ciphers in TLS 1.3: AES,
CAMELLIA, ARIA. One could also only define ciphersuites for AES. The
original paper only talks about the merits of OCB mode with AES - so
this would make sense. Since of the other ciphers are -- to some extent
-- based on AES, OCB mode would work perfectly fine with them, but then
again; who really uses them? I certainly agree that ciphersuite
pollution is not the best way to go. But having three different AEAD
block modes to choose from is.

Is this a reasonable proposal?

As for Jake's comment: Personally I fully agree with that, but can see
why the military exception would make it hard for IETF to have this mode
as mandatory to implement. So it'd probably end up as optional. Given
that support for OCB is already present in (some) implementations; this
would, again, make sense.

Aaron