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

[Rene Struik <[e-mail]>]

Hi Malisa:

I do not really understand the purpose of the "escape character 
clause".  Could you explain?

As follow-up of the Lake Virtual Interim of January 25, 2022 [1], it was 
suggested to took the question re suitability of certain MTI algorithms 
to the CFRG mailing list, which Stephen Farrel did (see email Fri Jan 
28, 2022, 4.14pm EST [2]). At this point, I have not seen any CFRG 
co-Chair moderating this or mediating a conclusion.

If the suggested text is a pretext to duck this discussion, I would be 
opposed to this. One should first conclude the CFRG consultation (for 
otherwise, this has just been a away to waste everyone's time).

Isn't the charter of the Lake WG to come up with a concrete light-weight 
protocol? Or, is now the idea to design "crypto with a hole" and 
delegate decisions regarding algorithm suites to some unknown entity 
outside IETF?

Ref:
[1] 
https://datatracker.ietf.org/doc/minutes-interim-2022-lake-01-202201251800/
[2] https://mailarchive.ietf.org/arch/msg/cfrg/Ev8hgyojKeObXMZ7SF2m3_yekMo/
[3] https://datatracker.ietf.org/wg/lake/about/
[4] https://datatracker.ietf.org/doc/html/draft-ietf-lake-reqs-04


On 2022-02-16 4:01 a.m., Mališa Vučinić wrote:
> Thanks, Stephen, for summing this up. While the “design meeting”  was 
> indeed informal, we have captured the main points and also logged the 
> presence. I append the notes from the meeting at the bottom of this 
> email. There seemed to be consensus on the proposed text. Still, the 
> formal record is the mailing list, so I kindly ask anyone objecting to 
> PR #239 [2] and Stephen’s proposed way forward to comment by 21 
> February 2022. By default, without further comments, the authors may 
> go ahead and merge the PR.
>
> Mališa
>
> [2] https://github.com/lake-wg/edhoc/pull/239/files
>
> =====================================================
> # EDHOC "design meeting"
>
> ## Date: 2022-02-10
>
> ## Present
>
> * Marco Tiloca
> * Rikard Höglund
> * Stefan Hristozov
> * Christian Amsüss
> * John Mattsson
> * Göran Selander
> * Carsten Bormann
> * Marek Serafin
> * Mališa Vučinić
> * Lidia Pocero
> * Blomqvist Peter
>
> ## Notes
>
> ### Authentication related processing #240
>
> * Goran goes through slide #3
> * CB: Application will work with the library, need to have an idea 
> about the abstractions provided
> * CA: Isn't the label available from out-of-band? GS: It can be 
> possible to have multiple at the same time (say, TTP and Remote 
> Attestation). CA: Makes sense then.
>
> #### EAD processing (slide 4)
>
> * CB: There needs to be at least one, better two fully documented 
> "applications" so people understand what these labels stand for
>
> ### Error messages #208
>
> CB: Errors that are part of the protocol should distinguish between 
> protocol information (modifying the other party's behavior) and 
> diagnostic information. If they are mixed, people will start parsing 
> messages. If error should have an effect, needs semantic definition 
> (including "does it make sense to retry?").
> GS: Consequence for proposals here?
> CB: Not entirely sharp. Application may provide some information to a 
> user too. Generally, if you can't imagine an effect of the error on 
> other party's behavior, no need to standardize that.
> Marek: (...) like sending supported suites, supported forms of 
> ID_CRED? JPM: Would require larger change, secure negotiation.
> CB: If you can not rely on security of error message (EDHOC doesn't 
> protect), can't rely. If MITM can create false agreement, there's a 
> problem.
> Marek: Error about suites is unprotected too; could have a similar 
> "don't support that ID_CRED"
>
> CB: Proposing name for that: "progress hint", hinting to other party 
> how to make better progress.
>
> ### G_X in simultaneous sessions #243
>
> MT: Receiving G_X, one has to check whether that's not already in use 
> with that party. Needs suitable code structuring.
>
> CA: Can requirement be narrowed to the cases that actually need it? 
> Iterating over whole system state can be costly.
>
>
> ### What test vectors in traces
>
> ### Further request on test vectors
>
> ### TLS-like compliance requirements #238
>
> Precede text with "In the absence of an applicability template 
> specifygin otherwise":
>
> can live with MTI suite 2 and 3,
>
> CA: Would prefer if whatever it says after "in absence of an 
> applicability template" is good for the CoAP/OSCORE/EDHOC case (as the 
> charter says this is tailored for this case)
>
> CB: term "applicability template" people do not understand; danger 
> that soemone tweeks the term to ensure that the whole thing becomes 
> unworkable.
>
> CB: look at TLS 1.3; it uses the term "application profile standard" 
> not "applicability template"
>
> GS: "applicability template defined in the draft
>
> CB: can we ensure that two parties talking EDHOC operate from the same 
> application profile?
> GS: No.
>
> =====================================================
>
>> On 15 Feb 2022, at 18:09, Stephen Farrell <[e-mail]> 
>> wrote:
>>
>>
>> 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] 
>>> <mailto:[e-mail]>>> on
>>> behalf of Mališa Vučinić
>>> <[e-mail]<mailto:[e-mail] 
>>> <mailto:[e-mail]>>> Date:
>>> Thursday, 20 January 2022 at 18:03 To:
>>> [e-mail]<mailto:[e-mail] <mailto:[e-mail]>>
>>> <[e-mail]<mailto:[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> 
>>> <https://github.com/lake-wg/edhoc/issues/22%3Chttps://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%3E>
>>>
>> [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> 
>> <https://mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_lsaM/%3Chttps://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%3E>
>>> [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> 
>>> <https://github.com/lake-wg/edhoc/pull/225/files%3Chttps://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%3E>
>>>
>>> -- Lake mailing [e-mail]<mailto:[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> 
>>> <https://www.ietf.org/mailman/listinfo/lake%3Chttps://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%3E>
>>>
>> <OpenPGP_0x5AB2FAF17B172BEA.asc>--
>> Lake mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lake
>
>

-- 
email:[e-mail]  | Skype: rstruik
cell: [phone] | US: [phone]