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

["Blumenthal, Uri - 0558 - MITLL" <[e-mail]>]

Good points!

Also, do we acknowledge that there will be specific applications that need
specific cipher suites that are not included in those few selected for
universal use (i.e. a couple of AEAD modes, a couple of block ciphers,
etc)?

For example, what if Russia insists on using Kuznetchik? Surely you don’t
expect everybody to implement it, but surely you don’t expect them to say
“IETF did not bless Grasshopper for TLS, so we’ll switch to AES-based
suites, or use ChaCha20”?

How are we planning to handle such “special” needs?
-- 
Regards,
Uri Blumenthal                               Voice: [phone]




On 1/13/15, 19:25 , "Viktor Dukhovni" <[e-mail]> wrote:
>On Tue, Jan 13, 2015 at 09:34:19PM +0000, Stephen Farrell wrote:
>
>> I don't get why additional options are at all attractive. In
>> fact, I think they're ugly.
>
>Yes, except that OCB might well have been the most attractive AEAD
>mode to implement, were it not for IPR and the history of how we
>got here.  On a purely technical basis it appears superior to GCM.
>
>> 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.
>
>It would be nice to get there some day.  However we're still actively
>discovering what works:
>
>	* Which EC curves and signature schemes to use
>
>	* Which modes to use
>
>	* Which stream ciphers to use (have we settled on ChaCha20 yet?)
>
>	* Which block ciphers to use (must TLS support CAMELLIA? SEED?)
>
>	* Which hash functions to use (though SHA-2 is holding up well)
>
>Plus of course TLS is used in a rather diverse set of applications
>whose needs vary.
>
>> 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 cipher suite 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.)
>
>This would then require per-application TLS "profiles", with
>per-application definitions of the two ciphersuites in question.
>I don't think that'll work just yet.
>
>We might be able to get away with approximately two choices per
>degree of freedom:
>
>    * Two public key systems (RSA and ECDSA and/or EdDSA, drop DSA?).
>
>    * A couple of block ciphers (AES and CAMELLIA, drop SEED, IDEA, RC2,
>...?).
>
>    * Two key lengths 128 and 256.
>
>    * One or two stream ciphers (ChaCha20 and ???).
>
>    * A couple of AEAD variants (GCM, Poly1305, OCB?)
>
>    ...
>
>Which should still be a smaller set of possible outcomes that the
>current ~327, but I think we are sadly far from having just two be
>realistic.
>
>-- 
>	Viktor.
>
>_______________________________________________
>TLS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls