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

[Nico Williams <[e-mail]>]

On Wed, Jan 21, 2015 at 05:58:57PM +0100, Aaron Zauner wrote:
> 
> Nico Williams wrote:
> > On Wed, Jan 21, 2015 at 08:15:45AM -0800, Eric Rescorla wrote:
> >> On Wed, Jan 21, 2015 at 7:17 AM, Aaron Zauner <[e-mail]> wrote:
> >>> Any comments on the idea of removing the following two ciphersuites from
> >>> the draft?
> >>>
> >>>      CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB = {TBD9, TBD9}
> >>>      CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB = {TBD10, TBD10}
> >>>
> >>> I don't see how these would be relevant to embedded devices.
> > 
> > If DHE_PSK is relevant to an embedded device then all cipher+mode
> > combinations might be as well.  Obviously OCB wouldn't be required to
> > implement, but that's no reason to exclude any one subset of ciphersuits
> > using OCB.
> 
> Well. No. Not really. Why would an embedded device prefer to do DHE over
> ECDHE? ECC operations are sure to be more efficient on embedded
> devices/IoT. That's was my reason to ask for removal.

Sure, but why not just deprecate/remove non-ECDH ciphersuites and be done?

> > But really, this is once more about the gross inefficiency (in terms of
> > registration as well as number of bytes used on the wire) of cartesian
> > explosion ciphersuites.  Can we fix this?
> 
> What's your suggestion to fixing this? [...]

Negotiate key exchange, server authentication, PRF, hash, and
cipher+mode separately.  (Cipher and mode go together, as not every mode
makes sense for every cipher, but key exchange should have no relation
to the choice of cipher+mode.)  Key exchange and server authentication
are closely tied in some cases (e.g., RSA key transport), but that's not
a problem (SSHv2 managed).

Nico
--