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

[Stephen Farrell <[e-mail]>]

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

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.

<no-hats>

With a random hat: the OCB RFC is an IRTF informational document
and had CFRG consensus for publication. Using that in a standards
track spec would require TLS WG consensus, and then IETF consensus.
So there's no magic, just the usual IPR processing that each
participant has to do for themselves. I'd be pretty confident in
a bet that the odd encumbrance of OCB will be a hard barrier to
overcome, but who knows.

Cheers,
S.