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

[Paul Wouters <[e-mail]>]

It should really mention the new exchange it introduces in the abstract.

Sent using a virtual keyboard on a phone

> On Nov 30, 2022, at 03:32, Valery Smyslov <[e-mail]> wrote:
> 
> 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.
>