[TLS] MTI suite (was Re: Inclusion of OCB mode in TLS 1.3)

On Wed, Jan 14, 2015 at 9:02 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Wed, Jan 14, 2015 at 6:46 AM, Aaron Zauner <azet@azet.org> wrote:
>>
>> 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.
>
>
> To be clear, this is just a statement of fact. I.e., TLS 1.3 can only be
> used
> with AEAD and these are the AEAD ciphers that are presently defined.
> The WG could adopt more AEAD ciphers or conversely, remove ones that
> currently exist.
>
> Speaking only for myself, it seems like AES-GCM is the leading candidate
> for the MTI for TLS 1.3, based on the fact that it's the most common
> AEAD algorithm with 1.2.

In my view that may be mistake. AES-CCM is supportable everywhere with
AES, while AES-GCM requires hardware multiplier support, which in the
embedded world can be less common. AES-GCM as MTI creates an effective
lower bound on devices that is quite high. The range of hardware that
can support it securely and efficiently is very narrow.
ChaCha20-Poly1305 is rare, but easy to support everywhere.

We have a similar balancing act with respect to ECC, although there
P256 is a much more obvious seeming choice.

Sincerely,
Watson Ladd

>
> -Ekr
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin