Re: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-01

CJ Tjhai <cjt@post-quantum.com> Fri, 09 February 2018 00:41 UTC

Return-Path: <cjt@post-quantum.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2216E127011 for <ipsec@ietfa.amsl.com>; Thu, 8 Feb 2018 16:41:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=post-quantum-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TA_wgv3p73M for <ipsec@ietfa.amsl.com>; Thu, 8 Feb 2018 16:41:16 -0800 (PST)
Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD7512DA22 for <ipsec@ietf.org>; Thu, 8 Feb 2018 16:41:16 -0800 (PST)
Received: by mail-ot0-x22d.google.com with SMTP id s4so6115337oth.7 for <ipsec@ietf.org>; Thu, 08 Feb 2018 16:41:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=post-quantum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vJ8U3N5pSMzifXVgxuOB6LhzjZlFoFTWQb6hB+ZBwZU=; b=FDd3I+9l5b04yQqV/g0o4wQRdMSHezF9OOg1Q/wpIy61SA6NfWQFzLwBO8OJe9hDaH ss5YD0S5cFc8NlLUIoXnwyKRE4vg9MR6ABA63DUwezsPumUKnKl+97xle4hdfvssjuTX 11oZbn8lNdJPdqs9YMVeU8CDfiXkj/od99LRyby2AbD6L35G2ud1IDAEDQq8EEKu8qTZ gdWtNttD6m2Fig2JkN8XPAqRNjwcuH0XOvPItxGmnIN1DEHHbZiVx98zFrCAtSmpxKUD rTEI7Ub/7ezadmoFCY70YwYScu0WaIAsa1/oo6bAy1M+jBLv+dvOd2JEL+xZFOBLnaCr 0QVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vJ8U3N5pSMzifXVgxuOB6LhzjZlFoFTWQb6hB+ZBwZU=; b=ayf3EkK/3pOUUEp7py6in6dWqctFqX2HD9t9vmVnGTnXOAKp3V1wqS36QJjUBWcI5M 0y8ueObaAxkynCA35fsJWvgI5s2kUwLi3nlqPFL5qiKJ1eZbNGUvNeRBQmmtGmtdi+fi PveE+LD7ATifTq7QXU/YjsoD2kSdQVPn1as8OtK8dTOnPU6wXgdIDOY2Xc4unzwvDpTA Ujj2f10TJjDpqlRal4CyYgKKUmBrwUosBBuDwH+i2/E9dVNm6KpYttI4gF8IJBG6XVqF KVO4Uzr2bV9txFRzFp9Ij6zRu4ZiUsPO5ftDEAZf6UNRUqG+6R8C/S3pjE5VbTmrEQ1o gthg==
X-Gm-Message-State: APf1xPCUe2j52N+o9vc1urEph8YeHqYlp7nL1LogM1X7X83NgrIrB50h qcOeON3HuO2UlyOTrxTI9atbC6p5hm2Sx3gC/w2S0WrfysE=
X-Google-Smtp-Source: AH8x226ISruqU3pmGozvK93HvbnsEDfeEhtVYgz8veJbeS79D/cSKykg4evYh/7rPFXIfSBl/M+QHuA3yfdnjbueSlY=
X-Received: by 10.157.48.81 with SMTP id w17mr790404otd.283.1518136875415; Thu, 08 Feb 2018 16:41:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.13.20 with HTTP; Thu, 8 Feb 2018 16:41:14 -0800 (PST)
In-Reply-To: <033701d39b5d$bf7f2140$3e7d63c0$@gmail.com>
References: <033701d39b5d$bf7f2140$3e7d63c0$@gmail.com>
From: CJ Tjhai <cjt@post-quantum.com>
Date: Fri, 09 Feb 2018 00:41:14 +0000
Message-ID: <CANs=h-UXGubRKH4xc_U4YHf2LgwatwsnL3173_0i59DGQo9wDw@mail.gmail.com>
To: Valery Smyslov <smyslov.ietf@gmail.com>
Cc: ipsec@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/KGGCd7MdEVSN_BD6OmbPFuXHcS4>
Subject: Re: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-01
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Feb 2018 00:41:20 -0000

Hi Valery,

Many thanks for your email and also your interest in our draft.


As we explain in detail below, we don't agree with your conclusion
that our proposal is overcomplicated, does not take into account what
is out there, and insecure. Even if some of the features that we
introduce deviate from standard operation, we did so after checking
with clients and vendors. One of the features that they are keen on is
the possibility of reusing KE payload to negotiate hybrid post-quantum
groups or proposals.

Please find below our response regarding the points you made.

1. Negotiation

We are glad to see that you also appreciate the need to negotiate a
hybrid group. As you may remember, we introduced a new Transform Type
in our version 00 of our draft and it had not been well-received in
IETF 99 Prague. We accept this push-back and it makes sense; since the
introduction of IKEv2, there has not been any new Transform Type
introduced. In fact, after IETF 99 Prague, we found out that there
exists IKEv2 implementations out there that will error out if they
receive an unknown Transform Type.

As you pointed out, according to RFC 7296, if a responder receives a
proposal with Transform Type that it doesn't understand, it MUST
reject the proposal. However, we found that this is not true in
practice. StrongSwan is a good example; consider you have two peers
running StrongSwan where the initiator introduces a proposal
containing a new Transform Type:

SA:
  Proposal 1:
    Transform Type 1: ENCR_AES_CBC
    Transform Type 2: PRF_HMAC_SHA2_256
    Transform Type 3: AUTH_HMAC_SHA2_256_128
    Transform Type 4: P-256
    Transform Type 6: New Transform Type
  Proposal 2:
    Transform Type 1: ENCR_AES_CBC
    Transform Type 2: PRF_HMAC_SHA2_256
    Transform Type 3: AUTH_HMAC_SHA2_256_128
    Transform Type 4: MODP-3072

It is assumed that the responder runs StrongSwan implementing standard
RFC 7296, hence it does not understand Transform Type 6. Instead of
rejecting Proposal 1 and considering Proposal 2, the responder ignores
Transform Type 6 (i.e. selecting ENCR_AES_CBC, PRF_HMAC_SHA2_256,
AUTH_HMAC_SHA2_256_128, P-256). The initiator clearly does not propose
this proposal. This particular case would only be okay if Proposal 2
offers P-256. This is one particular implementation peculiarity, there
will be others that behaves oddly. The point is, if we introduce a new
Transform Type, it is very likely that backward compatibility can no
longer be achieved.

Hence, we pick a DH group that denotes a hybrid group and negotiate it
using the existing KE payload.

On your email, you also mentioned that in the future, we could use KE
payload to carry small PQ KE payload. Then, some logic is required to
distinguish what is carried in IKE_SA_INIT and what is carried in
IKE_AUX; it looks messy.

2. Fragmentation

We remember that Tero did suggest to use an intermediary exchange
between IKE_SA_INIT and IKE_AUTH. However, after soliciting inputs
from a number of parties (both vendors and clients), it appeared that
the majority didn't like the idea of having this extra exchange as
introduced a considerable deviation from standard IKEv2 flow and felt
that we would just be introducing an IKE_SA_INIT fragmentation which
could be achieved by other mechanisms.

While IKE_AUX would be useful in environment where network is lossy,
we also need to consider the requirements for applications such as VPN
concentrator where connection rate is important, or peers that have a
considerable route trip time. We acknowledge that we have not included
any mechanisms to deal with loss packets in version 01 of our draft.
This is intentional as we would like to get the WG input on which
direction we should take our draft before going deeper.

In terms of DoS attacks, we do not mandate the use of cookie
mechanism, but when implemented, the responder can check that incoming
messages corresponding to the second round of our protocol (note that
this is the expensive round in which public-key operations are
performed and space is allocated) have been agreed previously in a
first round of the protocol. We also believe that your comment that
what you propose is substantially more secure is not true. An attacker
who can monitor exchange of messages and inject packets, can trivially
DoS a connection (e.g. when the initiator sends the initial "HDR,
SAi1, KEi, Ni", the attacker immediately responds with a "HDR, SAr1,
KEr, Nr" of his choosing before the real responder does). An attacker
who can modify the initial packets is not detected until later in the
exchange. Of course, this could require a significant amount of
resource allocation for post-quantum public data exchange. In our
approach, we could detect it before IKE_AUTH phase.

3. Large payload

We also hope that we don't end up having PQC ciphers with large
public-key. We don't mandate our proposed draft to support payloads
larger than 64KB. In fact, it is an added bonus of how we do
fragmentation.

Best regards,
Authors of draft-tjhai-ipsecme-hybrid-qske-ikev2-01

On 1 February 2018 at 13:08, Valery Smyslov <smyslov.ietf@gmail.com> wrote:
> Hi, this is a long message...
>
> I've looked through the -01 version of the QSKE draft. The draft has been expanded
> and now it covers such aspects as QSKE negotiation, fragmentation and transferring
> of payloads larger than 64K. I didn't review the draft in details, however after reading
> I have concerns over the technical solutions the draft proposes. In particular, I think that
> the problems of negotiation, fragmentation and representation of large payloads
> could be solved better.
>
> 1. Negotiation.
>
> The draft introduces a new negotiation mechanism to be used explicitly with
> multiple QS key exchanges. While the proposed mechanism looks like an ingenious
> way to deal with legacy implementations and as a powerful tool to negotiate
> complex policies, I don't think it is ever needed, since all this can be done
> using existing mechanism. How it can be achieved:
>
> Let's define a bunch of new Transform Types each defining some kind of QSKE:
>
> Transform Type 6 - Lattice QSKE
> Transform Type 7 - Code-based QSKE
> Transform Type 8 - Isogeny-based QSKE
> Transform Type 9 - Symmetric QSKE
> ...
>
> Each of these Transform Types must then be populated with Transform IDs
> for QSKE of corresponding type. It is also important to add NONE into each of these
> types.  The Initiator willing to combine QSKEs of specific types would include
> corresponding Transform Types populated with the Transform IDs the initiator
> deems acceptable. If NONE for some Transform Type is included, it means
> that this Transform Type is optional. IKEv2 requires the responder to select
> a combination of transforms such that a single Transform ID of each Transform Type
> is present. It means that the current SA payload syntax is able to represent the policies
> that the new negotiation mechanism in the draft is designed for. For example:
>
> SA:
>   Proposal1:
>     TransformType1: ENCR_AES_CBC
>     TransformType2: PRF_HMAC_SHA2_256
>     TransformType3: AUTH_HMAC_SHA2_256_128
>     TransformType4: 2048-bit MODP Group
>   Proposal2:
>     TransformType1: ENCR_AES_CBC
>     TransformType2: PRF_HMAC_SHA2_256
>     TransformType3: AUTH_HMAC_SHA2_256_128
>     TransformType4: 2048-bit MODP Group
>     TransformType6: LatticeQSKE_2
>     TransformType6: CodebasedQSKE_1, CodebasedQSKE_2
>   Proposal3:
>     TransformType1: ENCR_AES_CBC
>     TransformType2: PRF_HMAC_SHA2_256
>     TransformType3: AUTH_HMAC_SHA2_256_128
>     TransformType4: 2048-bit MODP Group
>     TransformType6: LatticeQSKE_1
>     TransformType6: LatticeQSKE_2, NONE
>     TransformType6: IsogenybasedQSKE_1, IsogenybasedQSKE_2
>
> In this example the Proposal1 is aimed for the legacy responders.
> Proposals  means that the classic MODP_2048 group
> must be combined with LatticeQSKE_2 and either CodebasedQSKE_1 or
> CodebasedQSKE_2. Proposal3 means that the classic MODP_2048 group must be
> combined with either IsogenybasedQSKE_1 or IsogenybasedQSKE_2 and may optionally
> be combined with LatticeQSKE_2.
>
> Legacy responders would ignore Proposals 2 and 3 since they contain
> unknown Transform Type. However they would pick Proposal1.
> QSKE-enabled responders would select either Proposal 2 or 3 depending
> on their policy.
>
> Re-using existing mechanism is much easier to implement since the parsing
> code is already there, as well as the interface with the local policy.
> This mechanism is flexible enough to express the policies from the draft.
> It doesn't have a round trip penalty when communicating with legacy
> responder. It assumes that classic KE is always present, however I can
> see it as a feature, not as a disadvantage (see the next topic in the message).
> And in the future it will be possible to add QSKE mechanisms into Transform Type 4,
> provided their public key are small enough (and their security is proved, of course).
> In this case no classic KE is more needed.
>
> One disadvantage of using SA payload comparing with the new mechanism from
> the draft is that it is less compact and complex policies can lead to the situation
> when SA payload size will become too large. However, there is a draft describing compact
> representation of IKE payloads that allows to significantly decrease SA payload size
> (https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-compact/)
>
> One more consideration. I assume that existing implementations are conformant with
> RFC 7296, which states (Section 3.3.6):
>
>    If the responder receives a proposal that contains a Transform Type
>    it does not understand, or a proposal that is missing a mandatory
>    Transform Type, it MUST consider this proposal unacceptable; however,
>    other proposals in the same SA payload are processed as usual.
>
> There were a concerns that some implementations could incorrectly
> reject the whole SA payload if they encountered an unknown Transform Type.
> To deal with such (crippled) implementations one more round trip and an
> additional logic would be needed (if we decide to deal with them ever),
> but I think that it'll be no more complex than the negotiation mechanism from
> the draft.
>
> Am I missing something here?
>
> 2. Fragmentation
>
> I think that defining a new fragmentation mechanism for IKE_SA_INIT is bad choice.
> We already have IKE fragmentation and it is more appropriate to re-use
> existing mechanism. It is possible to do it in a way suggested by Tero:
> https://www.ietf.org/mail-archive/web/ipsec/current/msg11563.html
> I've published a draft defining auxiliary exchange for this purpose:
> https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-aux/
>
> Comparing with a new fragmentation mechanism for IKE_SA_INIT defined in the draft,
> re-using the existing IKE fragmentation via an auxiliary exchange has the following advantages.
>
> - It is easier to implement. The IKE fragmentation is already supported by many vendors
>    and it is easier to add a new simple exchange than to complicate IKE_SA_INIT, that is already
>    quite complex. Note, that with the draft's proposal IKE_SESSION_RESUME exchange would
>    need to be modified as well. With auxiliary exchanges resumption will be supported for free.
>
> - It is substantially more secure. The way the draft deals with fragmentation is susceptible to DoS
>    attacks when an attacker injects bogus fragments poisoning reassembly buffer. Adding
>    cookie to the fragments. as the draft suggests to prevent this attack, doesn't help at all:
>    to inject bogus fragments an attacker need to know IKE SPIs, so he/she must be able
>    to view messages from the peers, and if he/she is able to do it, then he/she will also
>    know the cookie. So, the proposed defense never works. This attack is impossible
>    with the standard IKE fragmentation unless an attacker is able to break key exchange
>    in the IKE_SA_INIT in real time. I presume he/she would need QC for that and I hope
>    by the time it is possible we'll already have some QC-proof key exchange with small
>    public keys, so that it can be used in the IKE_SA_INIT and thwart the attack.
>
> - It is more robust. The problem with the approach suggested in the draft is that it
>    works very poorly in case of packet loss, because all the fragments are sent simultaneously.
>    If the number of fragments is small enough, then it doesn't cause major problems.
>    However, as the number of fragment grows, single packet loss results in resending
>    the whole bunch of fragments. If the packet loss is caused by congestion, then
>    momentary resending all the fragments would result in more congestion, that
>    would only make things worse. Standard IKE fragmentation is also susceptible
>    to this problem, since it wasn't designed to deal with more than a handful fragments.
>    This is no more true with QC-safe huge public keys. Ideally, each fragment
>    should be acknowledged individually, however in is generally impossible with IKE
>    request-reply paradigm (since reply fragments must also be acknowledged).
>    Fortunately, using several auxiliary exchanges for transferring QC-safe public keys
>    make it possible to at least make this problem less significant. The idea is
>    to perform several QC-safe key exchanges utilizing large public keys one by one:
>
>   HDR (IKE_SA_INIT, MID=0), SAi1, KEi, Ni,
>        [N(AUX_EXCHANGE_SUPPORTED)]  -->
>                                     <--  HDR (IKE_SA_INIT, MID=0), SAr1, KEr, Nr,
>                                              [N(AUX_EXCHANGE_SUPPORTED)]
>
>    HDR (IKE_AUX, MID = 1), SK {QSKE1i}  -->
>                                      <--  HDR (IKE_AUX, MID = 1), SK { QSKE1ir}
>
>    HDR (IKE_AUX, MID = 2), SK {QSKE2i}  -->
>                                      <--  HDR (IKE_AUX, MID = 2), SK { QSKE2ir}
>
>    HDR (IKE_AUTH, MID = 3), SK {SA, TSi, TSr}  -->
>                                      <--  HDR (IKE_AUTH, MID = 3), SK { SA, TSi, TSr}
>
>   So each of negotiated QSKEs is performed in a separate exchange,
>   thus reducing the number of fragments in case it is fragmented.
>   It is even possible to split any single QS key exchange in a several
>   IKE_AUX exchanges if the exchange is DH-like, i.e. if public keys are
>   of the same size and are generated independently.
>
>   [Actually the same problem with reliable transferring of large number
>   of fragments in case of QSKE will also arise in case of re-keying...
>   There are several possible solutions, but I think they can be discussed
>   separately.]
>
> So, I see no advantages of the new IKE_SA_INIT fragmentation mechanism
> over the re-using of existing one. Again, am I missing something here?
>
> 3. Large KE payloads
>
> The draft makes it possible to deal with public keys greater than 64K
> by means of a complex pointer-like system (integrated with proposed
> fragmentation mechanism). I think that it is too complex. I'd rather
> use simple approach, that is aligned with the re-using of standard
> IKE fragmentation described above.
>
> I propose that in case the public key is greater than 64K, it is
> split into several consecutive KE payloads in a single message.
> If several long public keys are present in the message, then
> all the payloads each key is split into must be grouped together.
> An example:
>
>    HDR (IKE_AUX, MID = 1), SK {QSKE1i, QSKE1i, QSKE1i, QSKE2i, QSKE2i }  -->
>     <--  HDR (IKE_AUX, MID = 1), SK { QSKE1ir, QSKE1ir, QSKE1ir, QSKE2ir, QSKE2ir }
>
> Here we have 2 large public key in a single message, QSKEi1 is split
> into 3 payloads and QSKEi2 is split into 2 payloads. Actually, I don't think
> it is a good idea to send several large public keys in a single message given
> the problems outlined above, but it is a possible construction.
> A better way would be:
>
>    HDR (IKE_AUX, MID = 1), SK {QSKE1i, QSKE1i, QSKE1i}  -->
>                      <--  HDR (IKE_AUX, MID = 1), SK { QSKE1ir, QSKE1ir, QSKE1ir}
>
>    HDR (IKE_AUX, MID = 2), SK {QSKE2i, QSKE2i}  -->
>                      <--  HDR (IKE_AUX, MID = 2), SK { QSKE2ir, QSKE2ir}
>
> And even better way would be (provided the QSKEs are DH-like):
>
>    HDR (IKE_AUX, MID = 1), SK {QSKE1i}  -->
>                                      <--  HDR (IKE_AUX, MID = 1), SK { QSKE1ir}
>
>    HDR (IKE_AUX, MID = 2), SK {QSKE1i}  -->
>                                      <--  HDR (IKE_AUX, MID = 2), SK { QSKE1ir}
>
>    HDR (IKE_AUX, MID = 3), SK {QSKE1i}  -->
>                                      <--  HDR (IKE_AUX, MID = 3), SK { QSKE1ir}
>
>    HDR (IKE_AUX, MID = 4), SK {QSKE2i}  -->
>                                      <--  HDR (IKE_AUX, MID = 4), SK { QSKE2ir}
>
>    HDR (IKE_AUX, MID = 5), SK {QSKE2i}  -->
>                                      <--  HDR (IKE_AUX, MID = 5), SK { QSKE2ir}
>
> [And I still hope that cryptographers won't leave us with only
> those QC safe key exchange methods that use huge public keys.
> I really don't want to transfer megabytes of keys just to create an SA
> to read my one hundred bytes long e-mail...]
>
> So, the bottom line. I think that the QSKE draft goes into wrong
> direction, suggesting over-complicated and insecure solutions
> and ignoring existing mechanisms that can be used instead.
> I hope the authors will re-consider this.
>
> Regards,
> Valery.
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec