-
GS presenting: https://datatracker.ietf.org/meeting/interim-2021-lake-05/materials/slides-interim-2021-lake-05-sessa-edhoc-traces-consolidated-00.pdf
-
GS: no changes to the draft, only on the GH branch with issues and PRs.
-
GS: 5 reviews, 3 of which closed/merged (p3). More issues remain (p4).
-
JM: On issue #213 "Security considerations on Connection IDs", some work is also ongoing in CoRE in the KUDOS draft to (re-)negotiate those https://datatracker.ietf.org/doc/draft-ietf-core-oscore-key-update/
-
Feature not in the draft yet; presented at https://datatracker.ietf.org/meeting/interim-2021-core-14/materials/slides-interim-2021-core-14-sessa-key-update-for-oscore-kudos-00.pdf
-
GS: (p5) re-explained the point about ciphersuites to support (0 and 1) or (2 and 3)
- MV: "Constrained" device is not really defined. "Endpoint" seems confusing. Why not "device"? What does "or" mean in this context?
- GS: Some devices support only EdDSA, so they have only ciphersuites 0 and 1. Some devices support only ECDSA, so they have only ciphersuites 2 and 3.
- MV: When does interop break?
- GS: If a constrained device supports only 0 and 1, while the other peer is also a constrained device supports only 2 and 3.
- SH: If 0 is supported, there is no reason to support 1. If 2 is supported, there is no reason to support 3.
- GS: This is getting to issue #22, for which reaching agreement was postponed.
- MV: Still important to nail this down for formal analysis and implementors.
- GS: So we should take a decision on issue #22 at the next interim?
- MV: Yes, it seems so.
- GS: The difference from the current -12 is 0->(0 AND 1) and 2->(2 AND 3).
- MV: Fine to not reopen the discussion today, but keep in mind this is for constrained devices with things to optimize and security properties.
- CB: The decision on #209 on p5 is uncontroversial.
- CB: The other decision on #22 about what signature scheme is MTI is interesting and orthogonal. My take is that on constrained devices people will use whatever they want and have available. The risk of non-interoperating is just not possible to prevent altogether. Another question is if we have a preference.
- MV: Not super pressing, but in the interest of formal analysis.
- SF: Not that we necessarily have to decide on this, implementors would do whatever they want anyway. We can also bring this topic on the list.
- Uri (on chat): Vendors that want to claim conformance to "an RFC", usually implement the necessary minimum, and either omit or charge more for "optional" stuff. I'd rather avoid 256-bit cipher suits being in that category
- GS: Can't reach an agreement today, but we need it soon.
- SF: Let's revisit the topic on the list.
- MV: Yes, if we don't reach a conclusion, let's have it at the next interim.
- --> ACTION FOR CHAIRS: Start/resume a thread about issue #22 on the list
- GS: (p6) clarified order of events when using EAD, e.g., in EAD use cases.
- SF: Good to have good security considerations on these points.
- GS: (p7) more issues, all handled
- MT: On the possible padding, it should be easier to say OPTIONAL to use for the sender, while mandatory to support in general (since it might be encountered by the receiver). There is an inline comment in a PR about this.
-
GS: Sounds good.
-
GS: (p8) more issues, also handled. We plan to send a summary and request for confirmation on the mailing list.
-
GS: (p9) IANA related comments from Kathleen, they need to be addressed.
-
GS: (p11,12) comments from Sean's review.