Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

Paul Wouters <paul@nohats.ca> Wed, 08 January 2020 17:22 UTC

Return-Path: <paul@nohats.ca>
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 C62811208AB; Wed, 8 Jan 2020 09:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 2N9JZm3B3e6I; Wed, 8 Jan 2020 09:22:22 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5AF1208B9; Wed, 8 Jan 2020 09:22:22 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47tGJr4xmrzF8S; Wed, 8 Jan 2020 18:22:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1578504140; bh=6KVFCd2LgWJ2409b2T2fHS5/aJdVVNWZA4K7YGgnWM0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ZlOhSp0bHBTZAyP2kXMYrKmxDSP02gbSlS9DAWnExg8KftikS8zEs+XotvECl7mrc n1aKlVKWmqoqBPUoxqbUFh8zTJmmbL3OkZk2WGomuKvM8mtTUnUjyy0SIhyxQ8BUBF XS8z2KuAB8dNOvTTI9C0wHwXliO+Ig0ZNFrWWm6M=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 7KqgiOpovlvc; Wed, 8 Jan 2020 18:22:19 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 8 Jan 2020 18:22:19 +0100 (CET)
Received: from [10.206.84.155] (199-7-157-32.eng.wind.ca [199.7.157.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 45BF26001425; Wed, 8 Jan 2020 12:22:18 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Paul Wouters <paul@nohats.ca>
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <8B631A80-F73A-4962-A292-4741A4B0CBE1@kuehlewind.net>
Date: Wed, 08 Jan 2020 12:22:17 -0500
Cc: Valery Smyslov <svan@elvis.ru>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-qr-ikev2@ietf.org, The IESG <iesg@ietf.org>, david.waltermire@nist.gov
Content-Transfer-Encoding: quoted-printable
Message-Id: <A5434DFE-B341-4578-9098-AEA073B4EAE9@nohats.ca>
References: <157840447348.21027.3875533519589774243.idtracker@ietfa.amsl.com> <BN7PR11MB2547A0216F2B8566B112811AC93E0@BN7PR11MB2547.namprd11.prod.outlook.com> <00bc01d5c605$ca5916f0$5f0b44d0$@elvis.ru> <8B631A80-F73A-4962-A292-4741A4B0CBE1@kuehlewind.net>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/uG9NCCT6GlDEEOWMuswQTsg9Jlw>
Subject: Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 08 Jan 2020 17:22:25 -0000

> On Jan 8, 2020, at 04:41, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
> 
>> 
>> I think one or two RTT is too short, moreover since it's an initial request,
>> no RTT is yet measured (IKEv2 uses UDP as primary transport).
>> We try here to be in line with core IKEv2 spec, which deliberately 
>> doesn't give any concrete figures of how long to wait for an response
>> (section 2.4 of RFC7296). So, I'd leave the text as is.
> 
> Kind of same here. Given you two disagree here already, I think it would be good to give further advise.

I agree with Valerie. We don’t do that on purpose. A 100gbps connection is different from a satellite connection. Let the implementation handle that part.


>> I agree with Panos: the downgrade is possible only if using PPK is optional
>> for both, in which case both parties agree that downgrade is OK.
> 
> Having some downgrade detection would enable to log an attack if optional PPK was used.

That would be lost in the noise when using mixed ppl/noppk use I think. As said, one is expected to only allow noppk during migration, which would be very limited in time (like hours or days for static tunnels, maybe weeks or a few months for remote access VPN updates to happen)

Paul