Re: [TLS] Consensus Call on MTI Algorithms

[Watson Ladd <[e-mail]>]

On Apr 2, 2015 11:49 AM, "Nico Williams" <[e-mail]> wrote:
>
> On Wed, Apr 01, 2015 at 11:12:19AM -0700, Joseph Salowey wrote:
> > [...]
>
> I'd like to have at least two required algorithms for each class, at
> least for the 128-bit security level.  The rationale is: to make it easy
> to switch one off if it becomes a problem.
>
> We've already had to disable broken algorithms in a hurry in several
> Internet protocols including TLS.  We should learn the lesson: we should
> aim to have at least one left.

Is that really what happened with RC4 and the MAC construction?  Or
was it nearly a decade of ignoring widely reported weaknesses?

>
> In all cases recall that required-to-implement != required-to-enable.

All sites with RC4 enabled and preferred implement and offer
AES128-SHA in the handshake. The absence of alternatives in
implementations isn't what is keeping RC4 alive.

>
> > o Symmetric:
> >         MUST AES-GCM 128
> >         SHOULD ChaCha20-Poly1305
>
> I would like at least two modes for AES to be required: one AEAD
> (probably GCM) and one AEAD-by-generic-construction (e.g., using HMAC).

OCB is a better fit constrained devices. CCM requires two passes.

>
> I would like one non-AES cipher to be required.  ChaCha20-Poly1305 works
> for me.

What does this requirement translate to in practice? It doesn't
necessarily mean that we can switch, as there is no requirement to use
the other ciphers, or even offer them. We seem to have quietly
admitted to opening up a zoo of ciphers, where every profile picks a
different one. How do these proposals actually improve security?

What we need to do is ensure that bad ciphers aren't used. The
exercise of ensuring that we have alternatives only matters if we have
an answer to the question of how migration works.

Sincerely,
Watson Ladd

>
> Total: three required algorithms.  Here I want three because I'm not
> sure that GCM is easy enough to implement and use safely in all
> environments (see Watson L.'s comments on this), and because I'd like
> two ciphers just in case.
>
> > o Hash:
> >         MUST SHA-256
>
> I would like two hash functions to be required.  I don't have a strong
> preference as to the second hash function, but I like SHA-3.
>
> > o Key Agreement: ECDH
> >         MUST P-256
> >         SHOULD 25519
>
> By the rationale above I would like both of these to be required.
>
> > o Signature:
> >         MUST ECDSA P-256
> >         MUST RSA
>
> Ditto.  We won't have the luxury of waiting until CFRG blesses an ECC
> signature scheme other than ECDSA, but when they do... we should add
> that to the list.
>
> Nico
> --
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls