Re: [Lake] Ways forward on MTI cipher suite text

[Michael Richardson <[e-mail]>]

Mališa Vučinić <[e-mail]> wrote:
    > crypto primitives. Existing devices can be expected to support either
    > ECDSA or EdDSA.
    > Cipher suites 0
    > (AES-CCM-16-64-128, SHA-256,8, X25519, EdDSA, AES-CCM-16-64-128,SHA-256)
    > and 1
    > (AES-CCM-16-128-128,SHA-256,16,X25519, EdDSA, AES-CCM-16-64-128,SHA-256)
    > only differ in size of
    > the MAC length, so supporting one or both of these is no essential
    > difference.

If it differs only in how many bytes are kept of the MAC length,
which means essentially no code differences, but 8 bytes on the wire,
I'd like to ask if we actually need both, period.

    > Similarly for cipher suites 2
    > (AES-CCM-16-64-128, SHA-256,8,  P-256, ES256, AES-CCM-16-64-128, SHA-256)
    >and 3
    > (AES-CCM-16-128-128,SHA-256,16, P-256, ES256, AES-CCM-16-64-128, SHA-256).

    > To enable as
    > much interoperability as possible, less constrained devices SHOULD
    > implement all four cipher suites 0-3. Constrained endpoints SHOULD
    > implement cipher suites 0 and 1, or cipher suites 2 and
    > 3. Implementations only need to implement the algorithms needed for
    > their supported methods.”

I want to suggest that Constrained endpoints implement:
  (0 xor 1)
  -xor-
  (2 xor 3)

either eat more bytes, or don't.
The device presumably knows what it's Tx power budget needs to be.
Beyond that, it's ECDSA vs EdDSA here, right?

If we wanted a spare suite "in case", then I'd prefer to have Chacha/Poly.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide