-
Main Changes -05 -> -06 (Göran Selander)
- Main changes:
- optional byte: to detect message 1 (depends on applicability statement)
- updates on error codes
- Change on recommendation for CoAp
- unchangesd test vectors
- applicability statement
- deterministic CBOR
- Always determinstic CBOR (e.g. credential encoding)
- Message deduplication
- Appendix on CDDL and change log
- Removed section on documents listing EDHOC
- Circular and not really needed
- Section on TEEs
- Clarifications (reviews PS & MT)
- Update references
-
EDHOC Open Issues (John Mattsson & Göran Selander, 40 mins)
- No major issues -> mostly optimization
- Issue: EDHOC and availibility -- If processing fails in any way -> discontinue and send error message. This is subject to a DoS attack (attacker sends a single byte and processing will fail). Soften this requirement?
- MV: An attacker can forge an error message and discontinue the handshake?
- JM: Yes, but an attacker can even send a single byte to discontinue the handshake
- JM: Maybe a MAC to error message, maybe not worth the complexity
- MV: what would we gain?
- JM: TLS first no error message with cryptographically protected, now some are
- SF: IPSec you can have unexpected messages (difference with TLS)
- SF: Will applications multiplex protected and unprotected traffic over the same port/URI ?
- JM: Maybe someone else can answer this question better
- JM: Small connection identifiers so easy to spoof (make a message be processed as message 3)
- CB: The use cases exist (multiplexing over same port/URI), normally sort/demultiplex traffic before start interpreting as EDHOC
-
Scope of the applicability statement
- List of things you need to agree on. Changed in draft to a policy framework (cipher suite and credentials were allowed?)
- Applicability statement has been tuned down again (no longer policy statement)
- CB: All TLS libraries allow you disable certain ciphers and I expect EDHOC to allow the same
- PS: How do they agree on the applicability statement?
- CB: Same issue in TLS (switching off older TLS version breaks sometimes the protocol)
- PS: not clear if C_1 is used
- GS: Should there be an extensive list of parameters to agree on?
- GS: from the applicability statement (e.g. on this URI), C_1 is used or not used, should be clear from the context
- MV: do we want the complexity of the CORR value ?
-
Forbidding multiple calls to EDHOC exporter
- No guidance on how to use the exporter?
- Prefix labels or context parameter (IANA registry)
- MV: personal opinion is that a seperate context parameter makes more sense
-
Next steps
- GS: Small design team/hackaton to solve the issues we keep running into.
- GS: Both hackaton and design questions planned for mid-May
- MV: Next interim early June/end May so the design team and hackaton can report
- JM: Pull request for 2 issues (issues related to intermediate hashes and encoding connection identifiers)
- JM: Need to discuss the level of optimization (now optimization to 45 bytes).
- MV: Optimization level based on 6TiSCH, coordinate offline
- GS: Marco send out doodle for Interim?
- MT: Yes
-
AOB