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

From: Karthik Bhargavan <[email-masked]>
Date: Tue, 14 Jan 2020 17:27:20 +0100

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

---

From: Göran Selander <[email-masked]>
Date: Wed, 15 Jan 2020 16:04:23 +0000

Hi Karthik,

Thanks for comments! My responses below.

Here are the updates I made to the draft:
https://github.com/lake-wg/reqs/commit/bc5a9644

On 2020-01-14, 17:27, "Lake on behalf of Karthik Bhargavan" <[email-masked] on behalf of [email-masked]> wrote:

    Dear All,

GS: Previous comments have requested some of these details, so there is a conflict here. Perhaps your reaction indicates that we are about to reach the right level of detail. More about Diffie-Hellman further below.

GS: Done.

GS: For this section I agree and changed accordingly. Later mentioning of Diffie-Hellman also contains requirements for supporting multiple and mixed public key credential types, and there I kept the mentioning of signature and static DH as illustrative examples.

GS: As far as understand, a lattice-based KEM is currently out of scope for the IETF but may be supported in a later version of this AKE.

GS: See above. There is also good reason to support static DH for the authorized enrolment application, I added a placeholder for that in section 2.6.

GS: I moved these paragraphs to section 2.4 "Crypto Agility and Security Properties".

GS: I reshuffled the content of section 2.3 accordingly.

GS: I rephrased this as "It shall be possible for the receiving endpoint to detect a replayed AKE message." Others may want to comment on this.

GS: I added a motivation for why the AKE needs at least 3 messages in section 2.3, see if you agree. I shortened the reasoning on Diffie-Hellman and made it an example.

GS: Forward secrecy is now discussed in section 2.4. Please propose a formulation if you think it should be reiterated here.

GS: I used your proposal to rephrase the current sentence related to guidance, but kept the specialized statement as the example.
    
More comments are welcome. If you think I skipped over something you like to discuss in one of the virtual interims, we/you can make an issue on the Github. 

Thanks,
Göran