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