Re: [saag] looking to hold a TLS VPN side meeting at IETF 92

Aaron Zauner <azet@azet.org> Tue, 24 March 2015 02:29 UTC

Return-Path: <azet@azet.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256391B2B97 for <saag@ietfa.amsl.com>; Mon, 23 Mar 2015 19:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 eQ5UZtKReFLw for <saag@ietfa.amsl.com>; Mon, 23 Mar 2015 19:29:03 -0700 (PDT)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (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 1471E1B2B95 for <saag@ietf.org>; Mon, 23 Mar 2015 19:29:02 -0700 (PDT)
Received: by wixw10 with SMTP id w10so81384468wix.0 for <saag@ietf.org>; Mon, 23 Mar 2015 19:29:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=hfhUrmYeX4Kh7mDvyNA2L7DjgRXoz8I02+dbz6GsVfg=; b=BSNyh8QqVYuNmTBedtqCuchDPVshP6LouSjLxjXBNmmpPxNhdwFey9gLKeyq3wLvN6 NS+DhAre0RUIC9fyI7ARrczkc7EWjFn8LnAR9RiVuCjDGcMeTzioBFIrCD+nrrtxEJmH ZKeXNAO7XCy04OSila0uymWRwf9UEKuCYKtl3ne7qlkpDUknCTCohpKEahwC+CnhIWqn /rbghHxdVkS0mgwtij51E/C4DcXKjDX66B5YLOSIopzEdkbAz9JDuaDkPmY+zpPcTQ6U E5lbXiRcMIi+ac4zbYZKn9aSLqASXquI2zJOwzcqabu2br+EIdKDCHi2Iz3BBaUS/Z/7 LKKg==
X-Gm-Message-State: ALoCoQk9mBflaWnl3WJ1Nb6YNpOMeR5W5pwbsR1COos1CZTe2L20XseD7eU91kQEq2J+MSOAgczs
X-Received: by 10.194.60.104 with SMTP id g8mr3619084wjr.96.1427164141537; Mon, 23 Mar 2015 19:29:01 -0700 (PDT)
Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id k6sm13778749wia.6.2015.03.23.19.28.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 19:29:00 -0700 (PDT)
Date: Tue, 24 Mar 2015 03:28:58 +0100
From: Aaron Zauner <azet@azet.org>
To: Tero Kivinen <kivinen@iki.fi>
Message-ID: <20150324022857.GA15592@typhoon.azet.org>
References: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B16@uxcn10-5.UoA.auckland.ac.nz> <5509CB2D.7060100@azet.org> <21770.45371.223543.54229@fireball.kivinen.iki.fi>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp"
Content-Disposition: inline
In-Reply-To: <21770.45371.223543.54229@fireball.kivinen.iki.fi>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/rcW52H65TugYK8gamaulKkrqCCY>
Cc: "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] looking to hold a TLS VPN side meeting at IETF 92
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2015 02:29:05 -0000

Hi Tero,

* Tero Kivinen <kivinen@iki.fi> [19/03/2015 12:21:36] wrote:
> Actually it is implementors fault, as they use obsoleted IKEv1
> protocol. IKEv2 obsoleted IKEv1 in 2005, but now ten years later,
> people are still using old version. IKEv2 fixed lots of issues in
> IKEv1, especially in the configuration end, for example making things
> like lifetimes local matter, so user does not need to configure or
> care about them, and they will not cause interoperability issues. Also
> things like you must use aggressive mode with road warriors with
> pre-shared keys went away, and the IP-address assignment and EAP in
> the base standard there is no need for non-interable versions of xauth
> and cfg-mode.
> 
> The problem is that with all its problems the IKEv1 still works "well"
> enough, that even if implementors implement IKEv2 they do not turn it
> on by default, i.e. they usually first try IKEv1. This means those
> implementations do not benefit from features provided by IKEv2.

I don't disagree, see previous mails and below. That being said,
it's still unclear to me why something like IKEv1 has been proposed
and standardized at all, but that was long before my time. Protocol
upgrades are a big issue throughout working groups and
implementations.

> How about proposing using non-obsoleted protocol, instead of proposing
> protocol that was obsoleted more than ten years ago? If the
> implementation you plan to use only supports IKEv1, then you know it
> has not been updated in last ten years, thus most likely it is not
> secure anymore.

This certainly wasn't my proposal. The issue I see is that a lot of
operating systems (not appliances) will default to IKEv1 or only
support IKEv1 (in the case of Apple). Thus the common denominator is
still IKEv1. I'd be happy to help design products that support
IKEv2. As is (i.e. without shipping a seperate application to
endusers) there's no real way to do that -- at least that I'm aware
of.

(We're going off-topic here, I'd suggest off-list CCs)

Aaron