Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

"Valery Smyslov" <svanru@gmail.com> Fri, 29 September 2017 15:21 UTC

Return-Path: <svanru@gmail.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 438C21321C9 for <ipsec@ietfa.amsl.com>; Fri, 29 Sep 2017 08:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 v5hFX5VLUj1c for <ipsec@ietfa.amsl.com>; Fri, 29 Sep 2017 08:21:54 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 D647F12EC30 for <ipsec@ietf.org>; Fri, 29 Sep 2017 08:21:53 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id r17so536842lff.6 for <ipsec@ietf.org>; Fri, 29 Sep 2017 08:21:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=2D3KcwHCcf0IwwyK0+tTz+K/ii6gSeED7SnNsddV7Ms=; b=cZXP86HqU7QyUvF4ZMSfmDGEJ/IRD6Wr4Ki7WINV4+c5tWx+iwOhCBuVBssd3G7ZJg ah9cSa3GZg0MI3AyUsHRX1eHRQe5r165s0jSTMfkykim6jHFmIef5Y1LqTuUMWDqv+qZ uf+1V5LrAm/1K6QqlbTYFS5y9OlolS4KA+jD0bm0nJpKD9wfefqTe/qP0lT7fdpC7p1R YtXWCGMwWCU7+G8xMY0urh5eUPtq4UPmB/BjPXvd9WvDs6L1yKIvKhGUvwg9/mt9fcat 74AyDUADDA6KuvP0rGIUtx7KF+rv9g+h7ySyRVjlUPTc4Zwj7dUjqZcrtg1M4CTSjQTn Zipg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=2D3KcwHCcf0IwwyK0+tTz+K/ii6gSeED7SnNsddV7Ms=; b=PL15cljXZXwLMn7+GB9ruvHEPModnq0lVrVDNbiPXalcOckS/LSFVLejexWk3ifdsO p6wLK2Cg49pUnWxPXBVWZ6AlN0VVUIfoLSATVYr0vY2oNjrLdtqglOmXxyO21N5z8kqg /tE8D39/4D0AuSun5Wi2v8pnYDG4vQ97+FolBxLhgRvqGFplooDO5WFshHMbT+TwZQji zJqDTy/CK9t61VNe7yJ8Tbl+nEeb5sqDpU/Ly+xPslNNqOjt/ukaE6p67HB1LRuxTm7D JyWnTR/iDMB0qI/kQCC/Njr+HOKxa+jBy3Vfq3FjrtrQvT8Gee2VV7X8ie20C463EFLM dI+w==
X-Gm-Message-State: AHPjjUhpAMM7qO7pr0jmqC4viLXytEpP634rbxZEnbmokQ0ICYezrUcT ZshAiyBeQQTnyz7Qw11YOJM5sw==
X-Google-Smtp-Source: AOwi7QDFM4Ac+4GtQ7NGzP/QElVHxlJoUQKGmr4idOoUih9y5b8bBMLpxy+KotzdMYyHg9KA7aLYhA==
X-Received: by 10.46.34.3 with SMTP id i3mr3664613lji.20.1506698511814; Fri, 29 Sep 2017 08:21:51 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h29sm828269ljf.36.2017.09.29.08.21.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Sep 2017 08:21:51 -0700 (PDT)
From: Valery Smyslov <svanru@gmail.com>
To: 'Paul Wouters' <paul@nohats.ca>
Cc: ipsec@ietf.org
References: <BBEB2C9C-9B96-4C6C-BB9B-4415F096FAE1@cisco.com> <041b01d30d21$8d33f230$a79bd690$@gmail.com> <1501968567726.89885@post-quantum.com> <22922.57101.227283.113155@fireball.acr.fi> <7769.1502301632@obiwan.sandelman.ca> <04B7D970-30B0-4AE8-BAF9-210746B56FFF@cisco.com> <14600.1506615504@obiwan.sandelman.ca> <00bd01d33922$a487c970$ed975c50$@gmail.com> <alpine.LRH.2.21.1709291052330.24648@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1709291052330.24648@bofh.nohats.ca>
Date: Fri, 29 Sep 2017 18:21:43 +0300
Message-ID: <00d001d33936$a8948800$f9bd9800$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJGClSbub5RkghZHKgMD6H8pOsCcwJfffzfAsuJTr8A5HSrWwGr2GqAAXTHICQBwMm63AHWDhOWAqAfTjmhax1WAA==
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/kVoDU6-ENRc74gqd3dDPtEpPaFw>
Subject: Re: [IPsec] Proposed method to achieve quantum resistant IKEv2
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, 29 Sep 2017 15:21:55 -0000

Hi Paul,

> >>    Adding IKE-level fragmentation to the process adds an additional place
> >>    that DDoS attacks can hit.
> >
> > We have DDoS protection mechanisms. I think it's possible to define
> > IKE_SA_INIT fragmentation so that these mechanisms be still able to work.
> 
> That would be tricky. 

Sure. But not impossible, I think.

> Either a new exchange or an untrusted stream of
> fragments. Either way, a lot of complexity for a rather moving target
> goal that we don't understand yet. I'd personally rather wait until we
> know a bit more about the direction that quantum safe protocols are
> really going to.

Fully agree. And the size of the quantum safe KE payload is really important for IKE.
When I hear that it could be several MB, it makes me nervous - it seems
that transferring so much unauthenticated data will become a good target for DoS attacks.
Several KB is a bit better, at least it seems that we can deal with this amount.

> >>    So, one would have to have some mechanism to know what would get through,
> >>    and if to switch to TCP, etc. before even trying.
> >
> > TCP has a lot of shortcomings. It's a last resort.
> 
> Agreed. It's the emergency backup parachute, not the real parachute.
> 
> People are suggesting a lot of complicated bells and whistles. I wish we
> would not compete with TLS on which can be more complicated :P

Haven't we already won? :-)

> Paul

Regards,
Valery.