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

[Göran Selander <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> wrote:

    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.

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.

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

GS: Done.
    
    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. 

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.
    
    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.

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.
    
    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.

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.
    
    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?

GS: I moved these paragraphs to section 2.4 "Crypto Agility and Security Properties".
    
    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.

GS: I reshuffled the content of section 2.3 accordingly.
    
    "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?

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.
    
    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.

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.
    
    Section 2.6 describes application-level security goals. This section may be a good place to discuss or reiterate forward secrecy.

GS: Forward secrecy is now discussed in section 2.4. Please propose a formulation if you think it should be reiterated here.
    
    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.

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