[Lake] comments on draft-ietf-lake-reqs

[Karthik Bhargavan <[e-mail]>]

Dear All,

In preparation for the virtual interim, here are some comments on the current version of the requirements doc (up to section 2.8)
A high-level concern is that in many early sections the requirements document text is too protocol-specific, and especially assumes protocols based on Diffie-Hellman.
It would be better to leave such details to the protocol design document and only state the high-level goals here.

Section 2.1: the acronym PFS is used here for the first time. Expand.

Section 2.2 says: "In order to allow for these different schemes, the AKE must support PSK- (shared between two nodes), RPK- and certificate-based authentication of the Diffie-Hellman (DH) key exchange.”
Here, and in later sections, the assumption that the AKE must support Diffie-Hellman is unnecessary and over-specific. All we want to say is that "the AKE must support PSK- (shared between two nodes), RPK- and certificate-based authentication” and leave out DH. 

More generally, I am assuming we do not want the requirements document to preclude all non-DH solutions, e.g those based on lattice-based KEMs.

Section 2.2 then says "Bandwidth is a scarce resource in constrained-node networks. The use of static DH public keys instead of signature public keys is a significant optimization and shall be supported.”
Again, this seems overly specific for a requirements document. Maybe just delete? Of course the protocol should optimize bandwidth but we already say so elsewhere.

Section 2.3 defines mutual authentication for LAKE.  
It then describes PFS, which feels a bit misplaced since it is not an authentication property. The same can be said for the bad RNG improvements paragraph. Maybe we should move these two paragraphs elsewhere?

Prevention of KCI resistance, identity misbinding, reflection attacks, are all specific cases of mutual authentication, and this should be clarified better. 
These are not additional authentication requirements; instead we should say that the mutual authentication guarantees of LAKE should be strong enough to guarantee these 3 properties.

"The AKE shall protect against replay attacks (injective)”: I am quite unsure what this means. What do we prevent from being replayed, the full AKE? The application messages?

Section 2.5 sets out the goals of identity protection. However, the third paragraph on how to protect PSK using DH and the trade-off between 3 and 4 messages seems too protocol specific. We have not even seen a protocol yet, so it is hard for the reader to even know why 3 messages is the “right” number for an AKE.

Section 2.6 describes application-level security goals. This section may be a good place to discuss or reiterate forward secrecy.

It also says: "It is expected that an AKE with 3 messages will provide the following protection of the application data”
Rather than providing specialized requirements for a 3 message protocol, it may be better to instead say that the LAKE 
protocol should provide clear guidance on the level of security provided to application messages at different stages of
the protocol. For example, the first message may be unprotected, … etc.


Best,
Karthik