Re: [IPsec] Proposed charter text
Tero Kivinen <kivinen@iki.fi> Fri, 16 February 2018 20:22 UTC
Return-Path: <kivinen@iki.fi>
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 B6F5012D77A for <ipsec@ietfa.amsl.com>; Fri, 16 Feb 2018 12:22:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
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 g4cTRIP7ItkB for <ipsec@ietfa.amsl.com>; Fri, 16 Feb 2018 12:22:14 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 9BF3C12D574 for <ipsec@ietf.org>; Fri, 16 Feb 2018 12:22:13 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1GKM7KH004997 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Feb 2018 22:22:08 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1GKM7Ad021706; Fri, 16 Feb 2018 22:22:07 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23175.15727.942705.428208@fireball.acr.fi>
Date: Fri, 16 Feb 2018 22:22:07 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Wouters <paul@nohats.ca>
Cc: ipsec@ietf.org
In-Reply-To: <alpine.LRH.2.21.1802161453320.23713@bofh.nohats.ca>
References: <23175.6913.726475.284090@fireball.acr.fi> <alpine.LRH.2.21.1802161453320.23713@bofh.nohats.ca>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 4 min
X-Total-Time: 4 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/WTrAHZbfujLeprQA-8vm8VT6gcY>
Subject: Re: [IPsec] Proposed charter text
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, 16 Feb 2018 20:22:14 -0000
Paul Wouters writes: > On Fri, 16 Feb 2018, Tero Kivinen wrote: > > > The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated > > RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec > > security architecture (RFC 4301). IPsec is widely deployed in VPN > > gateways, VPN remote access clients, and as a substrate for > > host-to-host, host-to-network, and network-to-network security. > > Can we add "mesh" to this, eg: > > and as a substrate for host-to-host, host-to-network, > network-to-network and mesh security. We could, but I think mesh is just host to host between lots of hosts pairs. I do not think we currently have anything that would really be directed for mesh security. > > Postquantum cryptography for IKEv2 (new) > > > > Postquantum Cryptography brings new key exchange methods. Most of > > these methods that are known to date have much larger public keys > > then conventional Diffie-Hellman public keys. Direct using these > > methods in IKEv2 might lead to a number of problems due to the > > increased size of initial IKEv2 messages. The working group will > > analyze the possible problems and develop a solution, that will > > make adding Postquantum key exchange methods more easy. The > > solution will allow post quantum key exchange to be performed in > > parallel with (or instead of) the existing Diffie-Hellman key > > exchange. > > I think "develop a solution" is a bit too strong here. We are developing solution to make adding postquantum key exchange methods easier. That does not necessarely mean we are solving the whole issue. > I think we are really "developing experiments to gain operational > experience" and in a latter stage "focus on providing a single > solution". Do you have proposed new text or actual changes for this item? -- kivinen@iki.fi
- Re: [IPsec] Proposed charter text Tero Kivinen
- [IPsec] Proposed charter text Tero Kivinen
- Re: [IPsec] Proposed charter text Michael Richardson
- Re: [IPsec] Proposed charter text Paul Wouters