Re: [IPsec] Warren Kumari's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

[Valery Smyslov <[e-mail]>]

Hi Warren,

thank you for your comments. Please see inline.

> -----Original Message-----
> From: Warren Kumari via Datatracker [mailto:[e-mail]]
> Sent: Wednesday, November 30, 2022 1:19 AM
> To: The IESG
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Warren Kumari's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-multiple-ke-10: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for writing this document (and also making it easy for someone like
> me to understand :-)) Also thanks to Geoff Huston for his DNSDOR review
> (https://datatracker.ietf.org/doc/review-ietf-ipsecme-ikev2-multiple-ke-07-dnsdir-lc-huston-2022-10-
> 10/)
> 
> I have a few non-blocking comments -- feel free to address them or not.
> 
> I think that moving Section 2, Bullet 2 towards to top of the document would
> help the reader better understand why this document exists...

Éric has suggested to put this or similar text to the Abstract, so it is now there.
The Abstract now is:

        This document describes how to extend the Internet Key Exchange Protocol
        Version 2 (IKEv2) to allow multiple key exchanges to take place 
        while computing a shared secret during a Security Association (SA) setup.
	
        The primary application of this feature in IKEv2 is the ability to perform one or more 
        post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman (EC)DH key exchange,
        so that the resulting shared key is resistant against quantum computer attacks.
        Since there is currently no post-quantum key exchange that is trusted at
        the level that (EC)DH is trusted for against conventional (non-quantum)
        adversaries, performing multiple key exchanges with different post-quantum algorithms along
        with the well-established classical key exchange algorithms addresses this concern, since the
        overall security is at least as strong as each individual primitive.
	
        Another possible application for this extension is the ability to combine several key exchanges 
        in situations when no single key exchange algorithm is trusted by both initiator and responder.

       This document updates RFC7296 by renaming a transform type 4 from "Diffie-Hellman Group (D-H)"
        to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num"
        to "Key Exchange Method". It also renames an IANA registry for this transform type 
        from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to 
        "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize 
        key exchange algorithms that can be used in IKEv2.

Is it OK?

> 1: "While solving such a problem remains difficult with current
>    computing power, it is believed that general purpose quantum
>    computers will be able to solve this problem, implying that the
>    security of IKEv2 is compromised."
> 
> 'solving such a problem remains difficult with current computing power' implies
> that they *can* be solved with current computing power, while 'it is *believed*
> that general purpose quantum computers will be able to solve this problem'
> implies that quantum only *might* be able to solve them...this makes it sound
> like quantum machines are less of a concern than current ones :-). Perhaps
> 'general purpose quantum computers will *easily* be able to solve this
> problem'? Or 'solving such a problem is infeasible with current computing
> power'? (handwaving away trivial parameters) My suggestion isn't great, but
> hopefully I've managed to explain my concern?

I see your point. I would use one of your suggestions, unless my co-authors disagree:

    While solving such
    a problem remains infeasible with current computing power, it is
    believed that general purpose quantum computers will be able to solve
    this problem, implying that the security of IKEv2 is compromised.

(I don't like "easily", since it's very subjective). 

> 2: Design Criteria - 3)   Focus on post-quantum confidentiality.
> I understand what this is trying to say, but it feels very disjointed. I don't
> really have any suggested test to fix it, but just dropping the last sentence
> (or folding it into an earlier one) would make it much much easier to read.
 
What if we rewrite this para a bit?

        Focus on post-quantum confidentiality.  A passive attacker
        can store all monitored encrypted IPsec communication today and decrypt it 
        once a quantum computer is available in the future. This attack can have serious 
        consequences that won't be visible for years to come. On the other hand,
        an attacker can only perform active attacks such as impersonation of the
        communicating peers once a quantum computer is available,
        sometime in the future. Thus, this specification focuses on
        confidentiality due to the urgency of this problem and 
        presents a defense against the serious attack described above, but 
        it does not address authentication since it is less urgent at this stage.

Is it better now?

The updated PR is available at:
https://github.com/post-quantum/ietf-pq-ikev2/pull/22

Regards,
Valery.