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

Aaron Zauner <azet@azet.org> Fri, 10 April 2015 12:23 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 755861B2E5F for <saag@ietfa.amsl.com>; Fri, 10 Apr 2015 05:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 7CxMGkfMTv8f for <saag@ietfa.amsl.com>; Fri, 10 Apr 2015 05:23:37 -0700 (PDT)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 672131B2E1A for <saag@ietf.org>; Fri, 10 Apr 2015 05:23:37 -0700 (PDT)
Received: by wizk4 with SMTP id k4so125983315wiz.1 for <saag@ietf.org>; Fri, 10 Apr 2015 05:23:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=xT0BIbMLma4UiGgrubiBwGIQk/re23opjrADDPvPHKw=; b=OxHzxJMqXYecRuAQbuW+S6RQxFjJzmm4drJ4+jz/NFtEQZTgaZTz/fgD11x3M5GeHw 2q+HwmYZ/2EwhoTwM79fUlVAPT/QRBFek41qgb2f8WZv2q0GbvBb795XkJUOP3J2uiRW AxGIWwaDUjQdeavqodB8vgxv+VuqXBodUmM+AMPw/XCUVcUSBkrq9lxk+Qtbu5qJu0Oa 8bjUYybQ18aVUS9/oZqknteQwrsLYnvghFe8jl69rYh9cMSIKUhRMHD7VLVWlQXMhpNg fY74iUE+qp79dE0SBJvsNtSocGTWJc2YI35/hNUCWn5mYDwiAw2MkFQvELCnd42bLIZt qO3A==
X-Gm-Message-State: ALoCoQkS/e4yELjqChDcIzDmSnKiuIvMSaAUgYkt1+S9trUXSfjVXY01OtXA3gF4I889vsWro37r
X-Received: by 10.194.79.199 with SMTP id l7mr2354960wjx.158.1428666849350; Fri, 10 Apr 2015 04:54:09 -0700 (PDT)
Received: from [192.168.23.81] (chello212017113090.11.11.vie.surfer.at. [212.17.113.90]) by mx.google.com with ESMTPSA id 14sm2641777wjv.0.2015.04.10.04.54.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Apr 2015 04:54:08 -0700 (PDT)
Message-ID: <5527B9DD.4020800@azet.org>
Date: Fri, 10 Apr 2015 13:54:05 +0200
From: Aaron Zauner <azet@azet.org>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Paul Wouters <pwouters@redhat.com>
References: <9A043F3CF02CD34C8E74AC1594475C73AAFB25C2@uxcn10-5.UoA.auckland.ac.nz> <BAD87999-DC8E-4E7A-BA14-E34874D6AA0F@gmail.com> <CAJU7za+ZBLbf3p4Zc1G2Uws88qCHxV4QmwZxUVjTYk2QzB62jQ@mail.gmail.com> <5508A726.5090406@azet.org> <551984FC.8020006@redhat.com>
In-Reply-To: <551984FC.8020006@redhat.com>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="------------enig0B22088E4B13F282D2908C7F"
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/m5Lro1zfdODwy9utVcyE6VHPlo8>
Cc: 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: Fri, 10 Apr 2015 12:23:39 -0000

Hi,

Paul Wouters wrote:
> On 03/17/2015 06:13 PM, Aaron Zauner wrote:
> 
>> IPSec might (!) work well if you use one vendor throughout your network,
> 
> That's a somewhat obsoleted viewpoint. While I think that is correct for IKEv1 and all the proprietary bold-on solutions, I do not see as many issues with
> IKEv2. Although for large scale solutions, there tends to be a strong vendor-lock but mostly in the management/gui aspects of having many devices (not endusers)
> 
>> solutions. Because IPSec is such an overly complicated protocol there's not much security in the clients that are available throughout enduser operating
>> system.
> 
> I'm not sure what you mean here. With the exception of group PreShared Keys and in particular Aggressive Mode IKEv1, yes that's broken and should not be used.
> But it _has_ been obsoleted for almost a decade now.
> 
>  Apple, for example, uses racoon (a NetBSD client) for
>> IPSec. It only supports IKEv1 in Aggressive Mode. That's a pretty big userbase that is forced to use an insecure protocol.
> 
> It does support IKEv2 in the latest iOS, but the provisioning is so locked up that people haven't made it work yet
> 
> It does suppor IKEv1 with certificates, which is _not_ insecure, even in Aggressive Mode.

And a lot of Users will struggle with configuring this. That's why Cisco
et al ship management solutions with e.g. AnyConnect. See below:

> 
> As for those still think IPsec is too hard to configure, according to http://www.theguardian.com/technology/2015/jan/09/why-netflix-wont-block-vpn-users there
> are 30 million people using a VPN to access netflix. With the apple vs android split, that's about 15 million end users who are using IPsec just fine.

Right. I've reviewed a lot of these services, most of them do _not_
support IKEv1 with Certificates but rather use a pre-shared key, which
most of them, put up publicly on their website. Some providers do have
better solutions, most offer a combination of Services with the primary
choice for endusers being OpenVPN or L2TP/IPSec (PSK public and the same
for all users).


Aaron