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

From: Göran Selander <[email-masked]>
Date: Mon, 14 Feb 2022 09:48:43 +0000

Hi,

As discussed in the design meeting last week 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:"

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

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 <[email-masked]> on behalf of "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wednesday, 26 January 2022 at 10:51
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]> On Behalf Of John Mattsson
Sent: den 26 januari 2022 08:04
To: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> on behalf of Mališa Vučinić <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 20 January 2022 at 18:03
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
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
[email-masked]<mailto:[email-masked]>
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>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Feb 2022 17:09:11 +0000

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:
> 

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. 

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.
> 
> From: Lake <[email-masked]> on behalf of "Blumenthal, Uri -
> 0553 - MITLL" <[email-masked]> Date: Wednesday, 26 January 2022 at
> 10:51 To: "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]> 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 <[email-masked]> On Behalf Of John Mattsson Sent:
> den 26 januari 2022 08:04 To: [email-masked] 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.
> 
> Cheers, John
> From: Lake <[email-masked]<mailto:[email-masked]>> on
> behalf of Mališa Vučinić
> <[email-masked]<mailto:[email-masked]>> Date:
> Thursday, 20 January 2022 at 18:03 To:
> [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> 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.”
> 
> 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 [email-masked]<mailto:[email-masked]>

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 16 Feb 2022 10:01:04 +0100

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 <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 <[email-masked]> wrote:
> 
> 
> Hi all,
> 
>> 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 <https://github.com/lake-wg/edhoc/pull/239/files>
> 
>> From: Lake <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> on
>> behalf of Mališa Vučinić
>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> Date:
>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> Subject: [Lake] Ways forward on
>> 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 list [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lake <https://www.ietf.org/mailman/listinfo/lake>

---

From: Rene Struik <[email-masked]>
Date: Tue, 22 Feb 2022 10:31:57 -0500

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
>
> * 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.
>
> * 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?").
> 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.
> 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.
>
>
> 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.
>
>>> From: Lake <[email-masked]<mailto:[email-masked] 
>>> <mailto:[email-masked]>>> on
>>> behalf of Mališa Vučinić
>>> <[email-masked]<mailto:[email-masked] 
>>> <mailto:[email-masked]>>> Date:
>>> [email-masked]<mailto:[email-masked] <mailto:[email-masked]>>
>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]>>> 
>>> Subject: [Lake] Ways forward on
>>> <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%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 [email-masked]<mailto:[email-masked] 
>>> <mailto:[email-masked]>>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>
>>>
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lake
>
>

-- 
email:[email-masked]  | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867