Re: [secdir] [Taps] Secdir early review of draft-ietf-taps-transport-security-04

Paul Wouters <paul@nohats.ca> Wed, 27 February 2019 15:29 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE64F130E71; Wed, 27 Feb 2019 07:29:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 QbpCOdfxGjK0; Wed, 27 Feb 2019 07:29:48 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 47CAA128CE4; Wed, 27 Feb 2019 07:29:48 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 448fkK3LKkzCg1; Wed, 27 Feb 2019 16:29:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1551281385; bh=Qb+o0RP13xCIrNfXz4k5c4WRkjyZWnAEySpGwVNZ8jU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iHjG3WoY7BHNGNj/WItz7XvI9G8qTqMk8rXmbfsJI30B6FATOw3jetjXSmirDiss0 I8v4yu0SOK27QhReiapoW++UXm4Gkyx1avS+KRCuYVRK4EsWKSZCZBd9NtpRIgXPfg oRdY07PPuGFCqBA1pzb9+83oe4qdYtYqdh1VKznk=
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 F_EQq6YB9K63; Wed, 27 Feb 2019 16:29:43 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 27 Feb 2019 16:29:43 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 362EFA7E0C; Wed, 27 Feb 2019 10:29:42 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 362EFA7E0C
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2CB9940D358A; Wed, 27 Feb 2019 10:29:42 -0500 (EST)
Date: Wed, 27 Feb 2019 10:29:42 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: Christopher Wood <christopherwood07@gmail.com>
cc: secdir <secdir@ietf.org>, draft-ietf-taps-transport-security.all@ietf.org, taps WG <taps@ietf.org>
In-Reply-To: <CAO8oSX=36n3v0vnUxki8bVHs5_NE3K55Wn=UCUeiEqpvChASWA@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1902271005140.3041@bofh.nohats.ca>
References: <154321083813.24275.4373340388504093292@ietfa.amsl.com> <03808BD3-11AA-4010-9B8D-7E33EC1FE39B@gmail.com> <CAO8oSX=36n3v0vnUxki8bVHs5_NE3K55Wn=UCUeiEqpvChASWA@mail.gmail.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/DhsSIyGtM01fvmk715ULM_Mz6rw>
Subject: Re: [secdir] [Taps] Secdir early review of draft-ietf-taps-transport-security-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 15:29:51 -0000

On Tue, 26 Feb 2019, Christopher Wood wrote:

> We just posted a revision to this document incorporating updates based
> on your comments [1]. (Thanks again for your careful review!) If you
> have time to check the diffs, we would greatly appreciate any more
> feedback you may have.

In general, the changes look good to me, although I still have
reservations about some of the toy protocols mentioned which just gives
them too much credibility. Thanks for adding openvpn. I see you did not
add openconnect/anyconnect, and kept in curvecp/minimalt. Not my
preference but if that's what the WG wants, I'm okay with it.

Note that the latest openvpn version now uses AES-GCM per default, so
perhaps you can excorsise blowfish from the document because Bruce
said not to use it like over a decade ago. If you do mention blowfish,
I think it should come with a big disclaimer to ensure people don't
think IETF belives it's okay to use. And I don't think we need to
point people to blowfish in the reference section.
(see https://openvpn.net/community-downloads/)

Just a few remaining questionts/comments left:

>>>         WireGuard is designed to be entirely stateless, modulo the
>>> CryptoKey
>>>         routing table,
>>>
>>> Wouldn't you be able to say the same about the ESP SPD/SAD table? I'm
>>> not sure
>>> how different the ESP/wireguard statelessness is on a scale or truly
>>> stateless
>>> to NFS

I'm still a bit concerned about the "designed to be entirely stateless".
As I said before, that's more of a marketing gimmick than an actual
technical property. Every VPN like protocol is stateless except for the
state it needs (a rule database, counters, crypto keys). I would suggest
removing this entire sentence:

    WireGuard is designed to be entirely stateless, modulo the CryptoKey
    routing table, which has size linear with the number of trusted
    peers.

>>> You do not mention mobility or session resumption for WireGuard. Since
>>> it is
>>> all about static inner IP addresses over arbitrary outer addresses, it
>>> has
>>> mobility. And I guess the 1RTT means it has session resumption?

You did not add these to the wireguard feature list.

>>> 5.1:
>>>
>>> Listed as mandatory feature is:
>>>
>>>    o  Public-key certificate based authentication.
>>>
>>> Yet you have mentioned that neither WireGuard or CurveCP can do
>>> authentication
>>> based on certificates?
>>
>> Indeed. This should read, “Public-key (raw or certificate) based
>> authentication.”

It seems you decided to completely remove the mandatory requirement?
What that on purpose or by accident?

Paul