Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-lake-chairs-slides-00
MV doing introductions
Document summary:
(no agenda bashing)
Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-lake-lightweight-authorization-using-edhoc-01
GF presenting.
GF (p2): Editorial improvements.
GF (p3): Reverse flow (U is the Responder). Allows heterogenous networks
to use one or another. (Technically, independent of reverse flow, when
using U and V identifiers instead of I and R).
GF (p4): Example comparing the default forward flow with the reverse
message flow. The parameters in the Voucher Request are generalized to
work with either flow. (beware bug in slides on the example on the
right: under V it should say initiator and under U responder)
GF (p5-7): Discussions during Hackathon: found problems with stateless
operation. Specifically, explicit inclusion of EDHOC message_1 is
needed. Discussion on generalization of parameters.
GF (p8): Constrained support may support only one flow; V should support
both, W is agnostic anyway.
GF (p9): Open issues #24 and #25 on OPAQUE_INFO, on making it less
opaque and actually specify it; no input yet. Can leave it, no need to
make more specific. When W is manufacturer, it's OK to be app specific.
GF (p10): More open issues. Next is to close those, towards a final
version to closely review.
GF: Hoping for final version once issues closed; along with updated
implementation.
(CA chat only): U shares its identity but may easily use a low-data
ID_CRED_R (like {} or '' or h'00') (so I don't think this is an issue
at all)
Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-lake-coordinating-the-use-of-application-profiles-for-ephemeral-diffie-hellman-over-cose-edhoc-00
MT (p2): Recap about contents. EDHOC peers need to agree on config
params. This document facilitates this through "application profiles".
Numeric identifiers for pre-arranged / well-known configurations.
Defining venues for where this info can be put and advertised.
MT: When used in EDHOC, still provides information in time before it's
too late.
MT (p3): Updates since last IETF. Draft was adopted. Editorial fixes.
Adopted comments from Michael Richardson and others. Clarify motivation
of the draft.
MT (p4): Technical changes: 1. Overview of where a profile identifier
can appear. 2. Set app_prof CBOR abbreviation to 23. 3. Ignore
unexpected parameters in the EDHOC_Application_Profile object
MT (p5): Moved multiple params to draft-ietf-ace-edhoc-oscore-profile.
Kept link target attributes in this draft.
MT (p6): Trust anchors discussed (with GS), in same namespace and ACE
document (but this document can do target attributes)
MT (p7-8): Introduced new "venue" for advertising this information: EAD
item in EDHOC message_1 or message_2 or EDHOC error message. A peer
can advertise its EDHOC capabilities through these also now.
MT (p9): Open issues: Presence of new EAD item in message_3/4
(pointless), multiple inclusions or malformed data in it, what to do if
it happens?
MT (p10): Next steps: Add examples. Please tell if you want it in JSON
too? Update list of well-known app profiles. More advertisement venues.
Security considerations.
CB, CA in chat: Want to not have that.
Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-lake-implementation-considerations-for-ephemeral-diffie-hellman-over-cose-edhoc-00
MT presenting.
MT (p2): Recap of contents. Scope, topics covered, things outside
vanilla EDHOC covered.
MT (p3): Updated references. Consistant language. Reorganized section 3
(trust policies).
MT (p3): Will need some help from authz authors to be realistic there.
MT (p4): Alignment with EDHOC and OSCORE ACE profile draft content.
MT (p5): Consistency checks of other peer's credential. A concrete
example is the EDHOC and OSCORE ACE profile, but things are phrased
generally.
MT (p6): Next steps: Content for learning policies in ELA. Processing
authentication credentials in EAD_1. Security considerations. Example
certs for plugtesting.
Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-lake-applying-grease-to-edhoc-00
CA (p2): Utilize existing codepoints (even if not used) to ensure
availability of them
CA (p3): Can we GREASE COSE headers (issue #1) ? Either: 1. Cannot use
as extension points to send more data, thus negotiation fails. 2. If we
can use it, let's GREASE it.
CA (p4): Open (issue #2): clarify to fail in case of critical use. It
should be clear already that only the initiator can effectively grease
through cipher suites.
CA (p5): Need to fix own libs, then happy to interop.
CA (p6): So mainly need an answer on greasing COSE and to team-up for
interop.
RN: You can mail the COSE mailing list asking for input
Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-lake-remote-attestation-over-edhoc-00
YS presenting
YS (p2): Recap of the protocol.
YS (p2): "background check model"
YS (p3): Recently adopted; added GS as co-author; updated based on
feedback
YS (p4): Added notion of time for freshness. Clarified network
attestation use case. Requirements on supported evidence types
YS (p5): Clarifications on evidence and trigger_*
YS (p6): Optimization for the background-heck model, not including the
evidence
YS (p7): Added new appendix on continuous attestation. open for
discussion, see issue #4
YS (p8): Next: error handling; section on the Verifier, clarify
meaning/use of C_R in the different setups (which might actually be not
necessary). Add appendix for combining "three As", attestation,
authentication and authorization.
MV: GS send mail to list about usage of EAD items as REST. Everyone have
a look
HB: This is shaping up well. I can do a review pass and file issues on
the Github.
Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-lake-edhoc-with-pre-shared-key-psk-authentication-00
ELP presenting
ELP (p3): changes since adoption. Updated title. (issue #1)
ELP (p4): Appendices on CDDL and test vectors. (issue #2)
ELP (p5): Fixed an issue with EDHOC message_3. Its original encoding
was not aligned with the data model from RFC 9528. Changed structure for
CIPHERTEXT_3. (issue #3) Appendix G of RFC 9528 applies in case of very
long plaintexts.
ELP (p6): Also in message_3, circular dependency made it impossible for
the Responder to decrypt. This eas fixed, changing how the keystream to
encrypt the first part of message_3 is computed. (issue #4)
ELP (p7): Prevent reflection/selfie attack. (issue #5)
ELP (p8): Added section on session resumption via resumption PSK
computed with EDHOC_Exporter(). Default values are defined. For the
key: the size of the key of the EDHOC EAD algorithm of the selected
cipher suite used in the session. For the key length, clearly not 1
byte, so it's really about 2 and 3 bytes (trade-off between risk of
collision and communication overhead in message_3). (issue #6)
ELP (p9): Also to ensure that a peer deletes the (previous) resumption
PSK when it is safe to do so (i.e., when it is ensured that the other
peer also has the latest one).
ELP (p10): Added IANA considerations on the EDHOC method and the
EDHOC_Exporter labels.
ELP (p11): Next steps: Self-contained doc vs. diff. Add test vectors.
Call for formal analysis.
TW: Coming from TLS where PSK integration was also considered. Security
suggest PFS property even in post-quantum compromise. Your keys are long
term, thus they cannot give post-quantum PFS.
TW: Essential that PSKs are unique between two parties.
CA, chat: I'd have thought uniqueness was implied in the PSK setting.
RML, chat: Yes, that is implied.
TW (on chat): in TLS on the discussion of RFC8773 and the formal
analysis triage of that draft, there was the notion of reuse of the PSK
credential across a group (because in that draft's setting it's also
additional), cf.
https://github.com/tlswg/rfc8773bis/blob/main/fatt-review/IETF%20FATT%20Report%20-%208773bis.pdf
ELP: If you only use PSK, then not guaranteed PFS. But combining with
ephemeral material.
TW: In PQ setting, the ephemeral part is gone.
MV: Please respond to this comment in next revision.
MV: Do you still not think you're ready for formal analysis?
ELP: Not ready, need to iterate.
MV: Say when.
Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-lake-discussion-on-quantum-resistance-00
JM: discussion on having EDHOC quantum resistant.
JM: Quantum computer will break ECC, have little effect on symmetric.
JM: Protection time and value of target affect migration time.
JM (p5): Discussion. No standard PQC have DH interface now. (Some in
literature, but not practical, not expecting this in 10y).
JM (p6-7): Overview of quantum-resistant key exchange.
JM (p8): Overview of quantum-resistant signatures. FN-DSA could suit
EDHOC. Expect several years until newer ones are standardized.
JM (p9): PQC algos are drop-in replacement for EDHOC for method 0 and
EDHOC-PSK. Problem is large sizes. As soon as a safe signature algorithm
is available in COSE, it can be used with method 0, after having
registered a new cipher suite that uses that algorithm. However, the
same does not apply with methods 1-3; new methods altogether need to be
defined. A CRQC would mean method 0-3 w. ECC lose all security.
EDHOC-PSK is less affected.
JM: Options are:
JM (p10): Using a symmetric PSK to be used in the methods 0-3.
JM (p11): Strawman of EDHOC exchange showing how PSK in method 0-3 could
work. Worth doing?
TW: Back to Group PSK thing. In TLS, had lot of discussion. Bluntly,
most quantum security claims are not valid in group setting.
JM: Dislike the group setting. Just added here b/c it was in TLS. If it
goes there, we remove it here too.
TW: Sig-sig EDHOC w. post quantum sigs will work. (Q: Which schemes,
which key exchange). FN-DSA is nice, but hard to implement correctly
(severe and easy-to-get-wrong side channels)
TW: MLBSA is probably prohibitatively large for here.
JM: Alg spec would be COSE, we use whatever is spec'd there, we just
pick them into suites.
TW: Interesting to investigate things like method 2: Initiator has KEM,
responder has signature key. Doesn't work because of identity
protection. If you give up on that, can do 2-RT protocol. Then, can do
KEM-SIG or KEM-KEM. Could be efficient, and get you away from FN-DSA if
R is a server (which can do FN-DSA properly)
JM: Very interesting feedback. Would need to specify tradeoffs.
TW: I'm interested to discuss. Tag me!
DS: You've stayed clear of hybrid. Due to LAKE constraints?
JM: Staying away b/c COSE would do all that work. Didn't want to get
into CSRG discussion. I'd favor hybrids in the beginning.
MV: So what do we do with PQ? Not in charter, just PSK. Shall we proceed
and how to proceed?
JM: Can continue discussing while waiting for algos to be standardized
in COSE.
MV: So keep discussing, decide later, no action item now.
TW: Protocol design work will take time, which people may not have with
2030 deadlines for some people. But up to those users to decide.
JM: A full revision of methods 1-3 would take years to do. ML-KEM and
FN-DSA are ready, could start, but major undertaking.
MV: So major work, we'd need to recharter.
MK: Lacking roadmap for devices in the field for long.
JM: You don't have to change protocols for post-quantum, it's about
upgrading those. That can happen via firmware update.
MK: But what about HW requirements? Do you need special elements? Is
this considered/happening somewhere?
JM: Maybe pquip is best venue
TW: It's all happening there, with drafts on guides for engineers about
this topics. I recommend to check those.
RN: COSE is probably the good venue to look at about this when it is
specifically about IoT. We wouldn't recharter until/unless really
needed. (RN: I am not against PQ-resilience, on the contrary, but as a
WG we should be careful to what we add to the charter. My point was we
need to be careful not to open a pandora's box)
Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-lake-bp-security-associations-and-edhoc-00
BS presenting.
BS (p2): Use case, embedding EDHOC into larger protocol. To be used in
delay tolerant environment (large delays, expected discontinuities,
ordering issues). Bundle Protocol has pre-existing security, behaves
similar to IPsec, relies on shared key material. Has no equivalent to
IKE or MACsec, desire to allow nodes in BP to have autonomy to establish
security associations. EDHOC to avoid reinventing the wheel.
BS (p3): Agent interactions. Layers. More complex than IPsec, but
similar fundamental concepts.
BS (p4): Want to avoid re-inventing things for BP security. PKIX exist,
avoiding new concepts. Want to operate in-band in BP (like IKE in
IP/UDP).
BS (p4): Both end-to-end and single-hop use cases.
BS (p5): EDHOC would be usable at the PDU (security) level. That would
be for the initial, mutual authentication phase, after which application
keys are exported to protect the main traffic.
BS (p6): Embedding EDHOC for Initial Authentication. But want to add
other interactions together with this, could use EAD items. Possibly
very constrained devices; details on sequencing may differ for them. PQ
roadmap is valuable.
BS (p7): Prototyping was done, based on the traces in RFC 9529. Working
on draft.
BS (p8): Next steps. Submit draft. Want improved EDHOC diagnostic
tooling.
CA (in chat): Sounds in line even technically (in addition to in-spirit)
MV: Please keep us updated, we'll find reviewers once draft is there.
No questions.
Interim Meeting before IETF 123@Madrid?
MV: Action item for chairs: Schedule interim midway before IETF123.
TK: IEEE working on adding EDHOC to 802.15.9, draft ready for ballot. If
you want to review it, can get you access. (6p + 16p boiler plate). Send
me a mail if interested.