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

[Stephen Farrell <[e-mail]>]

Hi all,

I had a brief mail exchange with Mališa so hopefully
this mail represents both chairs take on where we see
WG participants being on this topic, at this time...

On 14/02/2022 09:48, Göran Selander wrote:
> Hi,
> 
> As discussed in the design meeting last week 

Just to note for the record that that was an informal
meeting, not a WG interim. (Which is a fine thing and
not a problem.)

> there seemed to be an
> agreement for a similar formulation as TLS (see #238), in this case
> to prepend the cipher suite requirements with:
> 
> "In the absence of an application profile specifying otherwise:"

We don't think the above is controversial. (But do correct
us if that's wrong.)

> 
> This also considering that the term "applicability template" used in
> the draft is replaced by the more intuitive "application profile"
> (#250).
> 
> With this in mind, we have the option to be more strict in terms of
> cipher suites, since it may be overridden by an application profile. 
> One proposal is in PR #239.
> 
> https://github.com/lake-wg/edhoc/pull/239/files

That PR seems to us (in chair mode) to perhaps be closer to
what might constitute WG consensus at this time. If people
disagree with that and prefer the status-quo, please speak
up now. That reflects a pretty rough (or maybe weak)
consensus but it seems to be where we're at, as of now.
Assuming no objections, the editors should merge that PR
in a few days. (But please do come back to the list if
further non-editoral changes are needed for that merge.)

I'll note here that the CFRG chairs have agreed to put this
topic (signature schemes for small devices that can be under
adversary-control) on their agenda for IETF113. I hope that
that will eventually result in more clarity as to what LAKE
and other WGs ought adopt as MTI in such circumstances and
maybe even some better signature scheme.

But that'll take time and we believe LAKE WG participants
don't want to wait on that discussion terminating, hence
our suggestion we accept the above PR. If the CFRG discussion
produces some new facts before this WG is done, then we can
discuss those at the relevant time. If not, then edhoc is
extensible so better suites can be defined later as needed.

Cheers,
S.

PS: Just to avoid potential future confusion - PR#239 isn't
where I'd personally have landed myself, but as chair it
seems closest to what WG participants want, and it's clearly
a credible position to adopt. So while I might argue for
something else as part of the CFRG discussion, that doesn't
affect this consensus call.


> 
> Note that in PR #239 this condition is added at the top of the
> section, i.e. prepending not only the cipher suite requirements.
> 
> Further comments are welcome.
> 
> Göran
> 
> 
> From: Lake <[e-mail]> on behalf of "Blumenthal, Uri -
> 0553 - MITLL" <[e-mail]> Date: Wednesday, 26 January 2022 at
> 10:51 To: "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]> Subject: Re: [Lake] Ways forward on
> MTI cipher suite text
> 
> I have had a preference to EdDSA, but In light of presentation from
> Rene I don’t think it is reasonable to make EdDSA an MTI. I concur.
> 
> From: Lake <[e-mail]> On Behalf Of John Mattsson Sent:
> den 26 januari 2022 08:04 To: [e-mail] Subject: Re: [Lake] Ways
> forward on MTI cipher suite text
> 
> Hi,
> 
> I noticed to nobody has argued for EdDSA in the recent discussion.
> One potential way forward would maybe be to reformulate the current
> text without cipher suites 0 and 1. There has been several people
> expressing that they want the requirement to implement one or more
> cipher suite to be stronger. This would lead to Option 3 below.
> 
> - Option 3: Remove cipher suites 0 and 1 from the current text.
> Reformulate according to current discussion. Make implementation
> requirements for cipher suite 0 and 1 stronger for some types of
> implementations such as maybe less constrained devices, software
> libraries, non-closed deployments....
> 
> People typically have strong opinions on details. It is sometimes
> easier to agree on nothing. Option 4 below would align with what COSE
> is doing.
> 
> - Option 4: Just remove current text and replace it with nothing.
> 
> (I ignored the “2, 3, or 2 and 3” issue above, that also need to be
> discussed)
> 
> Cheers, John
> 
> 
> From: Lake <[e-mail]<mailto:[e-mail]>> on
> behalf of Mališa Vučinić
> <[e-mail]<mailto:[e-mail]>> Date:
> Thursday, 20 January 2022 at 18:03 To:
> [e-mail]<mailto:[e-mail]>
> <[e-mail]<mailto:[e-mail]>> Subject: [Lake] Ways forward on
> MTI cipher suite text Dear all,
> 
> During the last LAKE interim meeting, we discussed the issue of an
> MTI cipher suite and we agreed for the chairs to open a thread on the
> subject. As a reminder, the previous discussion points on this topic
> are summarized in github [1] and in John’s mail dated 13 May 2021
> [2].
> 
> We’d like to see if there is rough consensus in the WG on this topic,
> at this moment in time. Knowing that the formal analysis of the
> EDHOC-12 specification is under way, we should keep in mind that
> additional input may arrive down the road from teams working in the
> computational model.
> 
> As a reminder, the most recently discussed text for this is in a PR
> [3] and states:
> 
> “For many constrained IoT devices it is problematic to support
> several 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. 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.”
> 
> The options we see at this moment in time are:
> 
> Option 1: Keep current text as-is unless/until more feedback is
> provided that motivates re-opening this issue Option 2: Proceed with
> selecting a single MTI cipher suite
> 
> We'd like to know if the WG can live with Option 1. Note that doesn't
> mean you think option 1 is perfect, just that it's something with
> which you can live. If you prefer option 2 or some other option
> please suggest specific text.
> 
> Mališa and Stephen
> 
> [1]
> https://github.com/lake-wg/edhoc/issues/22<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-8d8739cc42e1d2b1&q=1&e=7f8ca305-4d94-4316-99c0-3b8e69e4bd77&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fgithub.com%2Flake-wg%2Fedhoc%2Fissues%2F22__%3B%21%21JmoZiZGBv3RvKRSx%21oMZFCrrtaAFUdL_LPHRBXf_uvG-p-6Y0b9jHb6jNGAPkgHq66wHpNbRb-twIjtmwJiui%24>
>
> 
[2] 
https://mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_lsaM/<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-8ee72b0658755668&q=1&e=7f8ca305-4d94-4316-99c0-3b8e69e4bd77&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Flake%2F75nRaD6czYG6RqLT06Qe8C_lsaM%2F__%3B%21%21JmoZiZGBv3RvKRSx%21oMZFCrrtaAFUdL_LPHRBXf_uvG-p-6Y0b9jHb6jNGAPkgHq66wHpNbRb-twIjmVyYhuw%24>
> [3]
> https://github.com/lake-wg/edhoc/pull/225/files<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-1c35d0ff14ead9d4&q=1&e=7f8ca305-4d94-4316-99c0-3b8e69e4bd77&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fgithub.com%2Flake-wg%2Fedhoc%2Fpull%2F225%2Ffiles__%3B%21%21JmoZiZGBv3RvKRSx%21oMZFCrrtaAFUdL_LPHRBXf_uvG-p-6Y0b9jHb6jNGAPkgHq66wHpNbRb-twIjjrL_38v%24>
>
> 
> 
> -- Lake mailing list [e-mail]<mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/lake<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-bbc313f3e273f8b1&q=1&e=7f8ca305-4d94-4316-99c0-3b8e69e4bd77&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake__%3B%21%21JmoZiZGBv3RvKRSx%21oMZFCrrtaAFUdL_LPHRBXf_uvG-p-6Y0b9jHb6jNGAPkgHq66wHpNbRb-twIjtnfowyW%24>
>
> 
>