Lightweight Authenticated Key Exchange
charter-ietf-lake-02

[Ballot comment]
No objections, but perhaps consider whether "Draft-selander-lake-authz is a candidate starting point for this work." needs to be in the final charter for the WG, or could perhaps just be elided.

[Ballot comment]
I agree with the others that the intro to the WG is quite long.

I also found this paragraph hard to parse:

Within each protocol message, EDHOC provides External Authorization Data (EAD)
fields. These fields may be used by external security applications to reduce
the number of messages and round trips, or to simplify processing. The working
group will specify the following uses of EAD fields to augment the EDHOC key
exchange: 3rd party-assisted authorization of EDHOC peers.
Draft-selander-lake-authz is a candidate starting point for this work. Remote
attestation of EDHOC peers, for instance using the available work from the RATS
working group. Status verification of EDHOC peer authentication credentials
transported during an EDHOC key exchange (e.g. OCSP stapling).

Stylistically, this might be clearer as something like this (if this is what is intended):

Within each protocol message, EDHOC provides External Authorization Data (EAD)
fields. These fields may be used by external security applications to reduce
the number of messages and round trips, or to simplify processing. The working
group will specify the following uses of EAD fields to augment the EDHOC key
exchange:

  - 3rd party-assisted authorization of EDHOC peers.  Draft-selander-lake-authz
    is a candidate starting point for this work.

  - Remote attestation of EDHOC peers, for instance using the available work
    from the RATS working group.

  - Status verification of EDHOC peer authentication credentials transported
    during an EDHOC key exchange (e.g. OCSP stapling).

[Ballot comment]
> Remote attestation of EDHOC peers, for instance using the available work from the RATS work group

Unbounded, this could be a large body of work.  Can the WG commit now to reuse the RATS work? or at least commit to adopting someone else's attestation framework.  It would be helpful to constrain this work in some way.

[Ballot comment]
I do not have any objections to the new charter although I agree with Eric Vyncke that the first two paragraphs could be removed.

[Ballot comment]
# GEN AD review of charter-ietf-lake-01-00

CC @larseggert

## Comments

### "IOTOPS", paragraph 1
```
  EDHOC (draft-ietf-lake-edhoc), an output of the LAKE working group, defines a
  lightweight authenticated key exchange protocol between two peers. EDHOC
  provides forward secrecy, mutual peer authentication, identity protection of
  the protocol initiator, and crypto agility. EDHOC was formally studied in
  different security models: its design reflects the academic community feedback
  that analyzed its security properties. EDHOC is intended to be used in
  constrained network environments such as NB-IoT, 6TiSCH and LoRaWAN.
 
  The primary purpose of EDHOC is to key the Object Security for Constrained
  RESTful Environments protocol (OSCORE, RFC 8613). EDHOC is based on Concise
  Binary Object Representation (CBOR, RFC 8949) and CBOR Object Signing and
  Encryption (COSE, RFC 9052 and RFC 9053) to minimize the message sizes and the
  memory footprint when used with other CBOR-based protocols.
  Draft-ietf-lake-edhoc is a dependency of documents in the CoRE, ACE, EMU and
  IOTOPS working groups.
 
  By publishing EDHOC, the base protocol specification, the LAKE working group
  has completed its initial goal. The working group will continue to work on
  draft-ietf-lake-traces, a draft gathering protocol traces in different EDHOC
  execution modes, and aims to maintain and extend the base protocol
  specification as appropriate.
```
This is *very* long. I think all you need as an intro is the first sentence of
the first paragraph, or maybe the entire first paragraph.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
While I have no objection on the content (except the intended status of the work items should be specified in the charter), I find the format of the charter quite unusual.

I.e., what is the purpose of the first 2 paragraphs about EDHOC ? They could probably be removed from the charter.

Regards

-éric

[Ballot block]
I have two questions I'd like to discuss before this goes out for external review:

1. What are "the security properties expected of IETF protocols"? I think it would be fair to conclude that different protocols have different security properties. Is there a document to reference or some other way to convey what is meant by this?

2. I'm a little unclear on the interaction between the "at most one" language and the text about the TLS WG. If the TLS WG produces a LAKE that satisfies the requirements that the LAKE WG specifies, would that count as the "one"? Or might the TLS WG produce one and the LAKE WG produce one? Or is the TLS WG not expected to work on a LAKE?